Deliverect · Rate Limits

Deliverect Rate Limits

Deliverect does not publish a dedicated public rate-limit page with concrete per-second numbers in its Developer Hub. Access is scoped per partner integration (OAuth 2.0 client credentials), and each connected customer account is accessed through the partner's credentials in production. The documented operational guidance focuses on token caching, HMAC-signed outbound webhooks, optional IP whitelisting, and separate staging and production environments rather than published request quotas. Because no numeric limits are published, the limit values below are descriptive strings and reconciled is false; partners should confirm enforced limits with Deliverect during certification.

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

It captures 3 rate-limit definitions, measuring varies.

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

Tagged areas include Rate Limiting, Restaurant, Delivery, and Integration.

3 Limits Throttle: 429
Rate LimitingRestaurantDeliveryIntegration

Limits

REST API requests (production) partner-integration
varies
not publicly documented; confirm enforced limits with Deliverect during certification
Access tokens are scoped per partner integration and grant access to each connected customer account. Specific request quotas are not published.
REST API requests (staging) partner-integration
varies
not publicly documented; staging is a shared test environment
Staging credentials are issued on registration before certification.
OAuth token issuance partner-integration
varies
cache and reuse the access_token until expires_at; do not request a new token per call
Tokens carry expires_at and expires_in; re-requesting per call is explicitly discouraged.

Policies

Token caching
Access tokens must be cached and reused until the expires_at timestamp. Requesting a new token for every API call is explicitly discouraged in the authentication documentation.
Webhook HMAC verification
Deliverect signs all outbound webhook requests using HMAC. Consumers should verify the signature on every inbound webhook rather than relying on retry volume.
IP whitelisting
Deliverect documents optional IP whitelisting for partner endpoints to constrain the source of inbound webhook and callback traffic.
Environment separation
Staging (api.staging.deliverect.com) and production (api.deliverect.com) are separate; load and burst testing should be done against staging, not production.
Backoff on 429
Treat HTTP 429 as a throttling signal and apply exponential backoff with retry. Concrete retry-after headers are not publicly documented.

Sources