> ## Documentation Index
> Fetch the complete documentation index at: https://docs.stackone.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Data Sync
> The engine that polls provider APIs on a schedule and stores the records in StackOne's indexes.
Data Sync polls a provider on a schedule you set and stores the records it returns in a StackOne index. You don't read that index directly. [Deep Query](/optimize/deep-query) searches and aggregates the stored records for you, without calling the provider.
You configure Data Sync once per action on a [Connector Profile](/gateway/concepts/connector-profiles). Every account on that profile is then synced automatically.
## How it works
* You turn sync on for an action on a Connector Profile, and set how often it runs.
* StackOne creates one sync per [Linked Account](/gateway/concepts/linked-accounts) on that profile, for accounts already linked and any linked later.
* Each time a sync fires it is a **run**, which fetches records from the provider and writes them to the index.
## Turn on sync for an action
Go to **Connector Profiles**, find the profile, and choose **Edit Profile**.
The tab lists every action on this connector that can be synced. The same actions carry a blue **Syncable** tag on the **Actions** tab.
Actions that need parameters to run, such as fetching one record by ID, aren't syncable and aren't listed. If the **Data Sync** tab isn't there at all, no action on this connector supports sync yet.
Toggle sync on for the action, then set **Sync every** and **Full re-sync**.
Saving starts the first sync immediately for every account already linked to the profile.
| Field | What it controls | Bounds |
| ---------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------- |
| **Sync every** | How often StackOne fetches new and changed records. Actions that can't sync incrementally re-fetch everything on every run and carry a **Full only** tag | 15 minutes to 365 days |
| **Full re-sync** | How often StackOne re-fetches everything from scratch, to catch deletions and repair drift. Only shown for actions that support incremental syncs | At least 1 day, and less frequent than **Sync every** |
Accounts linked after you save start syncing on their own first run, with no further configuration. You don't need to revisit the profile as your customers link accounts.
## Full and incremental runs
Most runs are incremental, because they're cheap. Full runs happen on their own interval to catch what an incremental run structurally cannot.
| | Incremental run | Full run |
| ------------------------- | -------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------- |
| Fetches | Only records that changed since the last successful run, using a checkpoint the previous run left behind | Every record |
| Runs | Every **Sync every** interval | The first run, then every **Full re-sync** interval, and whenever the connector's sync definition changes |
| Writes | Into the current set of records, in place | A complete new set, swapped in only once the run succeeds, so a query never sees a half-written result |
| Deletions at the provider | Not detected | Reflected |
| If it fails | The checkpoint is unchanged, so the next run covers the same window again rather than skipping records | The previous records stay readable |
Deletions only surface on a full run. A record deleted at the provider stays readable until the next full re-sync, because an incremental run has no way to learn that it's gone. Set **Full re-sync** to match how quickly you need deletions reflected.
## Monitor syncs
Go to **Accounts**, open an account, and choose the **Data Sync** tab. Each synced action gets its own panel showing its cadence and when it next runs. Expand a sync to see its recent runs: whether each was full or incremental, how long it took, and how many records it created, updated, left unchanged, or deleted.
The **Enabled** toggle is the one setting that's per-account. Turn it off to stop syncing an action for this account without touching the profile or any other account.
| Run status | Meaning |
| ------------ | ------------------------------------------------------------------------------------------------------------------- |
| `success` | The run finished and its records are readable |
| `running` | The run is in progress. The previously synced records stay readable until it finishes |
| `failed` | The run stopped on an error, shown in the row. The checkpoint is unchanged, so the next run retries the same window |
| `incomplete` | The run stopped without reporting a result. The next scheduled run resumes from the last checkpoint |
A sync shows **Paused** when the action, or sync for that action, is switched off on the Connector Profile. Nothing runs until it's turned back on.
## Limits
| Limit | Default |
| -------------------------------------------- | --------- |
| Records stored per organization | 1,000,000 |
| Storage per organization | 3 GiB |
| Providers synced per organization | 100 |
| Pages fetched in one run | 2,000 |
| Duration of one run | 6 hours |
| Record retention after the run that wrote it | 30 days |
The provider count means providers with at least one sync enabled, not actions. Syncing a second action on a provider you already sync costs nothing against it, and two Connector Profiles on the same provider count once.
Storage is measured in total record bytes, not fields, so there's no cap on how wide a record can be. A connector can lower the per-run page and duration ceilings for an action that needs it, but never raise them.
The page cap is usually hit first. In most cases, a run reaches 2,000 pages before it reaches 6 hours, so the duration ceiling is a backstop rather than the limit a run normally stops on.
Two more constraints are worth planning around rather than reading as numbers:
* **Not every action can be synced.** Actions that need parameters to run, such as fetching one record by ID, have no sync. See [Turn on sync for an action](#turn-on-sync-for-an-action).
* **Deletions wait for a full run.** Set **Full re-sync** to match how quickly you need them reflected.
Records expire once that retention window passes without a run. Any enabled sync refreshes them well inside it, so expiry matters mainly for a sync you disable and leave off: its records drop out, and reads against them start reporting nothing synced.
## Next steps
Search, filter, and aggregate the records a sync has stored.
Where sync is configured, alongside actions and events.