Skip to main content
Sync config controls, per data model: whether it syncs, how often, what access we request from the platform, and how far back to sync. It is set at the organization level and can be overridden per company.

​
The shape of a sync config

Each entry covers one data model: Entries that fail validation — an interval below 1, an unknown frequency — are skipped rather than rejecting the whole config, so a malformed entry silently drops that data model from the sync.

​
Frequency

frequency is one of HOURLY, DAILY, WEEKLY, MONTHLY, YEARLY, or NEVER. interval multiplies it, so the pair sets the real cadence:
  • frequency: DAILY, interval: 1 — once a day
  • frequency: HOURLY, interval: 6 — every six hours
  • frequency: WEEKLY, interval: 2 — every two weeks
NEVER disables Auto Sync for that model while still allowing manual syncs.
Pick the slowest frequency that meets your needs. The underlying platform’s rate limits are shared across every data model and your writes — see Syncing Data.

​
Access

scope_access is four independent booleans, not a single level:
Grant only what you use. The access you select determines the OAuth scopes we request from the platform, so over-requesting means asking your customers to consent to more than necessary.
Raising access after a customer has connectedWe only request the access level your config specifies at connection time. If you need more later, most integrations require the customer to re-authenticate to grant the additional scopes.

​
OAuth scopes

Scopes are the permissions your end customer grants for us to access their data. When a customer connects their platform, they see the data models and access levels you configured. We then request OAuth scopes matching those permissions. Most platforms also display the scopes being granted, so the customer sees the scope of data sharing before consenting.

​
Per-company overrides

Sync settings can be overridden for an individual company; the override replaces the organization-level config rather than merging with it.
An override must list every data model you want synced — models absent from it do not fall back to the organization config.Two adjustments happen on top of your entries at connection time: the config is filtered to data models the integration actually supports, and data models added to the platform after your config was written are appended with defaults so they still sync.
Set an override when creating an invite link, or later:
  • PATCH /v4/core/companies/{companyId}/sync-config
  • POST /v4/core/companies/{companyId}/sync-config/reset — drop the override and fall back to the organization config
  • POST /v4/core/companies/{companyId}/sync-config/reset/{dataModel} — reset a single data model
  • GET /v4/core/organizations/sync-config and POST /v4/core/organizations/sync-config — read and set the organization default
Per-integration access requirements are covered in each integration’s setup guide.