> ## 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.

# Data Replication

> How Terminal syncs provider data and the options for getting it into your systems.

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](/api-reference/data-management/request-sync) when you need a backfill or precise timing.

**Replication** is how *you* consume that data after Terminal has it:

| Method                                  | Best for                                               | How data moves                                                           |
| --------------------------------------- | ------------------------------------------------------ | ------------------------------------------------------------------------ |
| [API](/guides/syncing-via-the-api)      | Application logic, selective queries, custom pipelines | You pull with `modifiedAfter` / record-time filters                      |
| [Amazon S3](/guides/aws-s3-destination) | Warehouses, batch ETL, archival                        | Terminal delivers files to your bucket on a schedule or request          |
| [Kafka](/guides/kafka-destination)      | Event-driven systems, low-latency streaming            | Terminal produces records to your cluster as data is ingested or updated |

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.

```bash theme={null}
# Request a manual sync
curl --request POST \
  --url 'https://api.withterminal.com/tsp/v1/syncs' \
  --header 'Authorization: Bearer your_secret_key' \
  --header 'Connection-Token: con_tkn_your_token' \
  --header 'Content-Type: application/json' \
  --data '{"days": 90}'
```

## 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`](/guides/webhooks) (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`](/guides/webhooks) before treating files as complete — sync completion alone is not enough.

<Note>
  Current-state reads (for example latest vehicle location) are covered in
  [Real-Time Data](/guides/real-time-data), not this replication flow.
</Note>

## Choose a path

* **Building product features or a custom syncer** → [Syncing via the API](/guides/syncing-via-the-api) (includes the `modifiedAfter` convention and lookback guidance).
* **Loading a warehouse or lake on a schedule** → [AWS S3 Destination](/guides/aws-s3-destination).
* **Streaming into existing Kafka consumers** → [Kafka Destination](/guides/kafka-destination).
* **Triggering work when data changes** → [Webhooks](/guides/webhooks) (often used with the API path).