Skip to main content
Sandbox and production are two separate environments, each with its own https://<env>.kardinal.ai host, its own credentials, and its own data — nothing you create in one is visible from the other. Moving to production is mostly a matter of pointing your integration at the new host with new credentials and re-validating what you already tested, rather than a code change.

​
Differences between sandbox and production

​
Checklist before switching to production

  1. Confirm account-specific quotas (rate limit, max payload size, simultaneous-running-plans threshold) with support@kardinal.ai — these aren’t published and can differ from what sandbox happened to tolerate.
  2. Re-run your integration against production with real data volumes. If your production order/resource counts are meaningfully larger than what you tested in sandbox, re-check your maxOptimizationDuration sizing — see Handling large volumes rather than assuming sandbox-derived durations still apply.
  3. Re-verify geocoding. Kardinal does not geocode addresses (see Data model); confirm the same geocoding provider and pipeline used in sandbox testing is wired up for production data before go-live.
  4. Point any webhooks at the production environment’s URLs, if your integration uses them — a sandbox-configured webhook won’t fire for production plans.
  5. Rotate to production credentials everywhere, including any long-lived config or secrets manager entries — see the next section.

​
Managing API keys per environment

Kardinal doesn’t issue a separate long-lived “API key” — each environment has its own username/password pair, exchanged for short-lived tokens as described in Authentication and API keys. For production:
  • Store sandbox and production credentials as separate secrets, scoped to their respective deployment environments, so a staging deploy can never accidentally authenticate against production (or vice versa).
  • Confirm which environment a given access_token was issued against before debugging a request that behaves unexpectedly — a token from the wrong environment fails authentication rather than silently hitting the wrong data.
  • If you’re automating token refresh (see Token lifetime and refresh), point the refresh logic at the same <env>.kardinal.ai host the original login used.

​
See also