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

# Production Readiness

> A guide to help ensure your Terminal implementation is ready for production, covering what to have in place before going live so you can focus on the areas relevant to your use case.

## Consent Flow

1. Decide how you're integrating the [Link component](/guides/terminal-link): the [SDK](/guides/terminal-link#react-sdk) embedded in your app for a digital onboarding flow, or the [Hosted Page](/guides/terminal-link#hosted-page) sent directly to fleets for manual outreach.
2. If using the SDK, handle the `onSuccess` callback and [exchange the public token](/api-reference/authentication/public-token-exchange) for a connection token.
3. Open your Link page and confirm your application name and logo show correctly. This is what every fleet you send it to will see, and by default it falls back to your application branding. In sandbox you'll see a banner at the top of the page noting it's a test environment; that banner won't show in production. Optionally, use [Consent Templates](/guides/consent-templates) under **Add Connections > Consent Templates** in the dashboard for more control, such as a custom display name, logo, or theme colors.
4. Have a way to capture new connections: redirect handling, the [`connection.created` webhook](/api-reference/webhook-events/connection-created), [listing connections](/api-reference/connections/list-connections) from the API, or the dashboard.
5. Have a strategy for mapping connections to entities in your system: [`externalId`](/guides/custom-identifiers), [`tags`](/guides/custom-identifiers), or the connection ID Terminal assigns.

## Connection Lifecycle

6. Store the [connection token](/api-reference/authentication#connection-tokens) you get back after each fleet completes the Link flow. This token identifies which customer connection you're calling the API on behalf of, so store it securely like any other credential, and associate it with the corresponding entity in your system. Otherwise you won't know which token to use when you need to call the API or backfill data for that fleet.
7. Have a process for when a [connection becomes disconnected](/guides/disconnected-connections): an automated notification, manual outreach, or an in-app prompt.
8. Support [re-connecting](/guides/terminal-link#re-authenticating-a-connection) a connection when needed.
9. Decide how you want to handle [duplicate connections](/guides/duplicate-connections) to the same provider account.
10. Have a process for winding down connections for the different events that drive it: a fleet leaving your product, a customer data deletion request, cleaning up test or duplicate connections. Know when to [archive vs delete](/guides/deleting-connections#archive-vs-delete): archive stops syncing but keeps history; delete permanently removes the data.

## Data Access

You can use the [API](/guides/syncing-via-the-api), [S3 Data Delivery](/guides/aws-s3-destination), [Kafka](/guides/kafka-destination), or compare options in [Data Replication](/guides/data-replication):

### If using the API

11. Know which endpoints you're using and what data you're ingesting.
12. Handle [pagination](/api-reference/pagination) for list endpoints.
13. Track what data you've already synced, for example using `modifiedAfter` checkpoints.

### If using Data Delivery

14. Confirm where and how data is being delivered, and that your destination is connected and reachable.
15. Confirm you can see new files land and, if applicable, that you're receiving the corresponding webhook event.

### If backfilling historical data

16. Account for late arriving data with an appropriate [lookback window](/guides/syncing-via-the-api#late-arriving-data-&-lookback-windows).
17. Handle updates to previously synced records.

## Webhooks

If you're using [webhooks](/guides/webhooks), confirm which events you need and that you're handling them correctly:

18. Connection lifecycle: [`connection.created`](/api-reference/webhook-events/connection-created), [`connection.disconnected`](/api-reference/webhook-events/connection-disconnected)
19. Sync lifecycle: [`sync.completed`](/api-reference/webhook-events/sync-completed), [`sync.failed`](/api-reference/webhook-events/sync-failed)
20. Data Delivery lifecycle: [`delivery.completed`](/api-reference/webhook-events/delivery-completed), [`delivery.failed`](/api-reference/webhook-events/delivery-failed)
21. Data changes: [`vehicle.added`](/api-reference/webhook-events/vehicle-added), [`driver.added`](/api-reference/webhook-events/driver-added), [`safety_event.added`](/api-reference/webhook-events/safety-event-added)

See the [full list of events](/api-reference/webhook-events/overview) for more options.

## Billing

22. Understand the billing model. [Entities](/models/overview#entities) like vehicles and drivers don't cost anything on their own; they're only billed through the [real-time](/models/overview#real-time-data) or [historical](/models/overview#time-series-data) data you sync for them. Real-time data is billed per vehicle, per month, at your contract's real-time rate. Historical data is billed per vehicle-month backfilled, at your contract's backfill rate. Example: a new connection for 500 vehicles is made today. It immediately backfills 6 months of history. That's 3,000 vehicle-months of backfill (500 vehicles × 6 months), billed once. It then continues syncing real-time data. That's 500 vehicle-months billed every month for as long as the connection stays active. Over the following 3 months, that's 1,500 vehicle-months of real-time usage (500 vehicles × 3 months).
23. If you'll use [filtering](/guides/vehicle-driver-filtering) to limit ingestion to active vehicles or drivers, or [managed polling](/guides/managed-polling), factor that into your estimate since both affect what you're billed for.
24. Estimate your costs for the first three months in production using this model, based on your expected connection volume and how much history you'll backfill. Implementation choices like backfill depth, filtering, and managed polling change what gets metered, so knowing the model up front helps you make those tradeoffs deliberately instead of discovering the bill after go-live.

## Post Production Provisioning

25. Update your integration to the production [API base URL and secret key](/api-reference/environments).
26. If you serve multiple brokers or brands, set up a separate [consent template](/guides/consent-templates) or [short link](/guides/short-links) for each.
27. Reconfigure your [webhooks](/guides/webhooks) in the production portal. Sandbox and production webhook configs are separate.
28. If using [Data Delivery](/guides/aws-s3-destination), send Terminal your production destination setup (for example your production S3 bucket and access details), then update your production ingestion to read from that destination.
29. For each provider that needs app credentials in Terminal, complete that provider's configuration guide once your production app is provisioned.