> ## Documentation Index
> Fetch the complete documentation index at: https://developers.kardinal.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Moving from sandbox to production

> Environment differences and a production launch checklist.

Sandbox and production are two **agencies** of the same builder account — not separate hosts or separate logins. You sign up once; that single account gives you a long-term API token for each agency, and nothing you create in one agency is visible from the other. Moving to production is mostly a matter of pointing your integration at your production token and re-validating what you already tested, rather than a code change or a host change.

## Differences between sandbox and production

| Aspect | What differs |
| - | - |
| API token | Each agency has its own long-term API token — see [Authentication and API keys](/guides/authentication). A token issued for one agency does not work against the other. |
| Data | Plans, resources, and orders are entirely separate per agency — nothing in sandbox carries over automatically. |
| Host, sign-up, login | Identical — both agencies are served at the same host, `https://app.kardinal.ai/api/v2`; only the token you use determines which one a call applies to. |
| Credits | Plans submitted with a sandbox token don't consume credits; production plans do — see [Pricing and credits](/reference/pricing-and-credits). Run your smoke, schema, and modeling tests in the sandbox. |
| Routing | The sandbox computes every route crow-fly, whatever the `vehicleProfile`, and turns predictive traffic (`withTraffic`) off, with a warning: road network, traffic, and vehicle restrictions (height, weight, tunnels, hazardous goods) only apply in production. Test anything that depends on them with a production token. |
| Optimization time | The sandbox caps `maxOptimizationDuration` at 5 seconds (production: 6 hours by default) — enough to check that a plan is accepted and modeled as intended, not to judge the quality of an optimization on a real plan. Evaluate that in production. See [Limits and quotas](/reference/limits-and-quotas). |
| Rate limits | See [Limits and quotas](/reference/limits-and-quotas) for the full defaults, and contact [customer.success@kardinal.ai](mailto:customer.success@kardinal.ai) if your account's values differ. |

## Checklist before switching to production

1. **Confirm account-specific quotas** (rate limit, max payload size, simultaneous-running-plans threshold) against the [published defaults](/reference/limits-and-quotas); contact [customer.success@kardinal.ai](mailto:customer.success@kardinal.ai) if your account's values differ from the defaults.
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](/guides/handling-large-volumes#sizing-maxoptimizationduration-for-a-large-problem) rather than assuming sandbox-derived durations still apply.
3. **Re-verify geocoding.** The API does not geocode addresses (see [Positions and geocoding](/reference/data-model#positions-and-geocoding)); confirm the same geocoding provider and pipeline used in sandbox testing is wired up for production data before go-live.
4. **Rotate to your production API token everywhere**, including any long-lived config or secrets manager entries — see the next section.

## Managing your long-term API token per environment

Each agency has its own long-term API token, obtained via the Console, once per agency — not a separate username/password pair (see [Authentication and API keys](/guides/authentication)). For production:

* Store the `sandbox` and `production` tokens as **separate secrets**, scoped to their respective deployment environments, so a staging deploy can never accidentally authenticate against production (or vice versa).
* Confirm which agency a given long-term token was issued for before debugging a request that behaves unexpectedly — a token always authenticates successfully against its own agency, so using the wrong one doesn't fail: it silently succeeds against that agency's data instead. Check the `agencyId` field in the response to confirm which agency you actually hit.
* Regenerating a token **replaces** the previous one for that agency immediately — roll the new value out everywhere before discarding the old one (see [Token lifetime](/guides/authentication#token-lifetime)).

## See also

* [Authentication and API keys](/guides/authentication) — obtaining, rotating, and storing your long-term API token.
* [Limits and quotas](/reference/limits-and-quotas) — rate limits, payload size, and SLA, and how to confirm the values for your account.
* [Handling large volumes](/guides/handling-large-volumes) — sizing `maxOptimizationDuration` and paginating for production-scale data.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.