Skip to main content
  1. Decide how you’re integrating the Link component: the SDK embedded in your app for a digital onboarding flow, or the Hosted Page sent directly to fleets for manual outreach.
  2. If using the SDK, handle the onSuccess callback and exchange the public token 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 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, listing connections from the API, or the dashboard.
  5. Have a strategy for mapping connections to entities in your system: externalId, tags, or the connection ID Terminal assigns.

​
Connection Lifecycle

  1. Store the connection token 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.
  2. Have a process for when a connection becomes disconnected: an automated notification, manual outreach, or an in-app prompt.
  3. Support re-connecting a connection when needed.
  4. Decide how you want to handle duplicate connections to the same provider account.
  5. 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: archive stops syncing but keeps history; delete permanently removes the data.

​
Data Access

You can use the API, S3 Data Delivery, Kafka, or compare options in Data Replication:

​
If using the API

  1. Know which endpoints you’re using and what data you’re ingesting.
  2. Handle pagination for list endpoints.
  3. Track what data you’ve already synced, for example using modifiedAfter checkpoints.

​
If using Data Delivery

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

​
If backfilling historical data

  1. Account for late arriving data with an appropriate lookback window.
  2. Handle updates to previously synced records.

​
Webhooks

If you’re using webhooks, confirm which events you need and that you’re handling them correctly:
  1. Connection lifecycle: connection.created, connection.disconnected
  2. Sync lifecycle: sync.completed, sync.failed
  3. Data Delivery lifecycle: delivery.completed, delivery.failed
  4. Data changes: vehicle.added, driver.added, safety_event.added
See the full list of events for more options.

​
Billing

  1. Understand the billing model. Entities like vehicles and drivers don’t cost anything on their own; they’re only billed through the real-time or historical 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).
  2. If you’ll use filtering to limit ingestion to active vehicles or drivers, or managed polling, factor that into your estimate since both affect what you’re billed for.
  3. 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

  1. Update your integration to the production API base URL and secret key.
  2. If you serve multiple brokers or brands, set up a separate consent template or short link for each.
  3. Reconfigure your webhooks in the production portal. Sandbox and production webhook configs are separate.
  4. If using Data Delivery, 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.
  5. For each provider that needs app credentials in Terminal, complete that provider’s configuration guide once your production app is provisioned.