Sync frequency
Sync frequency is the rate at which an integration polls Qoyod or pushes data to Qoyod to keep both systems consistent. Choosing the right interval for each data type is a balancing act between data freshness requirements, operational cost, and the rate limits Qoyod enforces on API requests. This page covers what drives that decision and how different data types warrant different cadences; it does not cover which direction data flows — see Sync directions for that.
What determines sync frequency
Four factors shape the right polling interval for any given data type.
Data freshness requirements. The most important input is how stale data can be before it causes a problem. A discrepancy in available inventory quantities that persists for thirty minutes may be acceptable in a wholesale context but catastrophic for a retail storefront with live customers. Before settling on an interval, identify the maximum tolerable lag for each data type and let that bound your decision. Tighter freshness requirements push intervals shorter; looser requirements give you room to reduce load.
Rate limits. Qoyod enforces per-account request limits that set a hard ceiling on how frequently any single endpoint can be polled. You cannot push past this ceiling by polling faster — requests above the limit receive an error response and do not return data. The practical consequence is that the rate limit is your maximum frequency, not your target frequency. See Rate limits for the specific numbers and error codes.
Volume of changes. The volume of records that change between two polls determines how much work each poll produces. If a product catalog of ten thousand items changes fewer than fifty records per hour, a long interval wastes little — but the same interval applied to a high-transaction invoice stream could mean large catch-up payloads at each poll. High change volume is an argument for shorter intervals and robust incremental fetching; low change volume allows longer intervals without meaningful staleness.
Operational cost. Every API request consumes tokens from your rate limit budget and adds latency overhead. An aggressive polling schedule on a low-priority data type burns budget that could have been used by a time-sensitive one. Assign intervals deliberately rather than defaulting to the shortest feasible interval across all types.
Two broad approaches exist for triggering polls. Scheduled batch polling fires on a fixed timer regardless of whether anything has changed — simpler to implement and predictable. Event-triggered polling fires in response to a signal in the integrated system and then fetches the corresponding Qoyod record to confirm state. Event-triggered polling concentrates requests on moments of actual change, which is more efficient when changes are sparse.
Frequency by data type
Different data types in an inventory integration have different change rates and freshness tolerances. The table below gives practical cadence guidance. These are starting points; calibrate to your specific freshness requirements and rate limit headroom.
| Data type | Typical change rate | Suggested cadence | Notes |
|---|---|---|---|
| Product catalog | Low — deliberate and infrequent | Every 1–4 hours | Shorter intervals rarely justified |
| Inventory levels | Medium — changes with each transaction | Every 5–15 minutes | Use incremental fetch |
| Prices | Low to medium — controlled by pricing events | Every 30–60 minutes | Typically batched |
| Orders and invoices | High during business hours | Every 1–5 minutes during active hours | Adaptive scheduling recommended |
Operational constraints
Rate limits bound your maximum frequency
Qoyod enforces request rate limits at the account level. When your integration exceeds the limit, Qoyod returns an error response. Calculate your maximum theoretical request count across all polling jobs, confirm it stays within your rate limit, and add headroom for bursts. See Rate limits for specific values.
Cursor and timestamp tracking for incremental polls
Incremental fetching requests only records changed since the previous successful poll. The integration must persist a cursor or timestamp durably after each successful poll. On the first run a full fetch is necessary. Do not advance the cursor until a full poll has succeeded.