Apideck · Rate Limits

Apideck Rate Limits

Apideck does not publish a single global rate-limit number for its Unify API. Effective limits are determined by (1) Apideck's own per-application throttling and (2) the downstream connector's native rate limits (Salesforce, QuickBooks, Xero, HubSpot, etc.) which Apideck proxies and surfaces on 429. Apideck recommends honoring upstream Retry-After headers and using exponential backoff. Plan tier governs Active Consumer count and category access rather than a documented per-second cap.

2 Limits Throttle: 429
Rate LimitingUnified APIIntegrations

Limits

Apideck platform throttling application
varies
see provider documentation
Apideck does not publish a fixed per-second number; throttling is applied at the application and consumer level to protect shared infrastructure.
Connector (downstream) rate limits connector
varies
governed by downstream connector
When an upstream SaaS (Salesforce, QuickBooks, Xero, HubSpot, etc.) throttles, Apideck propagates a 429 with the upstream Retry-After.

Policies

Backoff Strategy
Implement exponential backoff with jitter; honor Retry-After when returned by Apideck or the underlying connector.
Connector Awareness
Effective throughput depends on the downstream system's native limits. High-volume use cases should partition workload across consumer connections and respect per-connector quotas.
Fair Use
Sustained traffic that materially impacts shared infrastructure may be throttled regardless of plan tier; engage Apideck support to align on burst patterns.
Webhook Replay
Use webhooks plus subscribe/poll patterns rather than tight read loops to reduce request volume against rate-limited connectors.

Sources