Paragon · Rate Limits

Useparagon Rate Limits

Paragon does not publish a single, transparent public rate-limit table. Because Paragon is an embedded integration platform, effective throughput is bounded by two layers: (1) Paragon's own per-project limits on Connect API, ActionKit, and Managed Sync calls, which vary by plan and are raised for Enterprise agreements; and (2) the rate limits of the underlying third-party APIs being proxied or synced (e.g. Salesforce, Slack, HubSpot), which Paragon surfaces back to callers. Managed Sync additionally manages its own ingestion concurrency, backfill pacing, and automatic retry/backoff on behalf of the application.

Useparagon Rate Limits is the machine-readable rate-limit profile for Paragon on the APIs.io network, conforming to the API Commons Rate Limits specification.

It captures 4 rate-limit definitions, measuring requests and records.

The profile also includes 4 backoff/retry policies defined and response codes documented for throttled.

Tagged areas include Integration, iPaaS, Embedded Integrations, ActionKit, and Managed Sync.

4 Limits Throttle: 429
IntegrationiPaaSEmbedded IntegrationsActionKitManaged SyncRate LimitingQuotasThrottling

Limits

Connect API Requests project
requests
see provider documentation
Per-project limits on zeus.useparagon.com SDK endpoints; varies by plan.
ActionKit Run Requests project
requests
see provider documentation
Rate on POST /projects/{id}/actions/run; downstream provider limits also apply.
Proxy API Requests user
requests
bounded by third-party provider
Proxied calls are subject to the connected third-party API's own rate limits.
Managed Sync Ingestion project
records
managed by Paragon
Backfill pacing, incremental sync concurrency, and retry/backoff are handled by Paragon.

Policies

Tiered Limits
Per-project limits are raised as accounts move from Startup to Growth to Enterprise agreements.
Downstream Passthrough
Proxy and ActionKit requests inherit and surface the underlying third-party API rate limits.
Managed Backoff
Managed Sync automatically retries with backoff and recovers from third-party failures during backfill and incremental syncs.
Client Backoff
Clients should implement exponential backoff with jitter and honor Retry-After on 429 responses.

Sources