Skip to main content
Terminal keeps each connection’s telematics data up to date by syncing from the provider. Once that data is in Terminal, you choose how to get it into your systems.

​
Sync vs replication

Sync is Terminal pulling and normalizing data from a telematics provider (TSP). Most connections use automatic background sync; you can also request a sync when you need a backfill or precise timing. Replication is how you consume that data after Terminal has it: You can use more than one method (for example API for product features and S3 for analytics).

​
Sync modes

Automatic sync mode (default): Terminal automatically keeps your connection’s data up to date by running syncs in the background. Most connections use this mode, which is typically configured during connection setup. Manual sync mode: You control when syncs happen by requesting them through the API. Use this mode when you need precise control over sync timing or costs.

​
Shared lifecycle

  1. Sync — Terminal ingests and normalizes data for the connection. Syncs are either scheduled automatically or requested manually.
  2. Data available — Records are ready in Terminal. Listen for sync.completed (or poll sync status) when you need to know a sync finished.
  3. Replicate — Pull via the API into your system, or wait for destination delivery. For S3 Data Delivery, wait for delivery.completed before treating files as complete — sync completion alone is not enough.
Current-state reads (for example latest vehicle location) are covered in Real-Time Data, not this replication flow.

​
Choose a path

  • Building product features or a custom syncer → Syncing via the API (includes the modifiedAfter convention and lookback guidance).
  • Loading a warehouse or lake on a schedule → AWS S3 Destination.
  • Streaming into existing Kafka consumers → Kafka Destination.
  • Triggering work when data changes → Webhooks (often used with the API path).