Go-live checklist

Moving from the sandbox to production changes hosts, credentials and data at once. Walk this list before the first production call, then watch the first day of traffic.

Credentials and access

• A production API key, created in the production tenant at https://kentro.app. Sandbox keys do not work in production.
• Its permission group holds only the scopes the integration uses, and the key is bound to the sales channels it writes into. See API keys and scopes.
• The secret sits in a secrets manager, not in code, configuration files or logs.
• A record of which system holds which key, and who can rotate it.

Hosts and ids

• Every host switched: apis.kentro.dev to apis.kentro.live (Channel API, Store API, authentication), pixel.kentro.dev to pixel.kentro.live, and Kentro OS from https://kentro.cc to https://kentro.app.
• No sandbox id left in configuration: channel ids, warehouse ids, product ids and storefront hosts all differ in production. Read production ids with GET /v1/channels and from production documents.

Requests

• An Idempotency-Key on every Channel API write, built from the source system's own ids so a retry reuses it.
• externalId on every create, and onDuplicate chosen on purpose (update for feeds that replay, error where a duplicate is a bug).
• Money in the right form: decimal strings in currency units on the Channel API, integers in minor units on the Store API.
• One day of real traffic replayed against production with X-Dry-Run: true, every document answering 2xx.

Errors and limits

• Branching on error codes, not on messages; retries only for 429, 503, 409 in_progress and network failures, with the same idempotency key. See Errors, retries and rate limits.
• The request id (requestId or X-Request-Id) logged with every refusal.
• Peak volume estimated against the Channel API defaults (1,200 writes and 6,000 reads per minute per tenant), with bulk loads going through POST /v1/orders/import and POST /v1/products/import.
• Bearer tokens refreshed before their 15 minutes run out.

Data

• History loaded with X-Import-Mode: historical, so old documents send no confirmation emails, packing slips, accounting exports or EDI documents.
• Incremental sync watermarks (updatedSince) set to the go-live moment, and each poll walking its pages to the end before advancing.

Custom storefronts

• The production storefront is published, its custom domain verified, and X-Storefront-Host is the live host.
• Every Store API call comes from the server; no key or token appears in a browser bundle.
• Refresh on the first 401, X-Expected-Buyer on every call, and X-Storefront-Client-Ip set from the buyer's address.
• Checkout tested end to end in the sandbox: a paid order, a decline, a provider authentication step (needs_action) and a lost checkout.start answer recovered with checkout.status.
• Cache-Control: no-store respected: nothing buyer-specific cached across requests.

Kentro Pixel

• A production property (pk_live_ key) with its allowed origins, consent wired to the site's consent banner, revenue sent from the server with a server key, and events visible in the property's Debugger. See Measure with Kentro Pixel.

After launch

• Watch the first day's 4xx, 5xx and 429 rates and the request ids behind them.
• Keep the sandbox key: changes are tested there first.
• Disable the keys of retired integrations.
• Read the Developer changelog for changes that affect the integration.