Rate limiting

Sales Layer APIs apply rate limits to protect platform availability, prevent accidental overload, and provide consistent service to all customers.

Current limit

The current documented limit is:

Exceeding this limit may result in temporary throttling or request rejection.
Design integrations so they stay below this threshold during normal operation and recover gracefully if the limit is reached.

How to interpret the limit

The limit applies to API traffic sent to Sales Layer. Client applications should avoid assuming that they can safely send bursts of requests up to the exact maximum on every time window.
For production integrations, keep a margin below the documented limit. This helps absorb retries, parallel workers, scheduled jobs, and user-triggered actions that may happen at the same time.

Recommended client behavior

Build API clients with explicit request pacing:

• Queue outbound API requests instead of sending all pending work at once.
• Limit concurrency across workers, background jobs, and user actions.
• Use pagination to process large result sets in smaller batches.
• Avoid unnecessary polling.
• Cache data when repeated reads do not need real-time freshness.
• Log request volume by integration, tenant, endpoint, and time window when possible.

Handling throttling or rejection

If a request is throttled or rejected because of excessive request volume, the client should slow down before retrying.

Recommended behavior:

• Stop immediate repeated retries.
• Wait before sending the next request.
• Retry temporary failures with exponential backoff.
• Add jitter to retries so multiple workers do not retry at the same instant.
• Reduce concurrency if throttling continues.
• Alert the integration owner if throttling is persistent.

Do not retry validation errors, malformed requests, or authentication failures without changing the request. Retrying those errors increases traffic but cannot make the request succeed.

Example retry strategy

Use a conservative retry strategy for temporary failures:

Attempt 1: send request
Attempt 2: wait 1 second, then retry
Attempt 3: wait 2 seconds, then retry
Attempt 4: wait 4 seconds, then retry
Stop and surface the error if the request still fails

The exact values can be adjusted for the integration, but retries should always have a maximum number of attempts.

Batch and synchronization jobs

For batch imports, exports, and synchronization jobs:

• Process records in batches.
• Keep a global rate limiter for the whole integration, not only per worker.
• Avoid launching multiple scheduled jobs that compete for the same API limit.
• Prefer incremental synchronization when possible.
• Resume from the last successful item instead of restarting the full process after a temporary failure.

Monitoring recommendations

Production integrations should monitor:

• Requests per time window.
• Error rates by status code.
• Retry counts.
• Average and peak request concurrency.
• Long-running jobs that generate sustained API traffic.

This information helps distinguish normal temporary throttling from integration design issues.

Support

For technical questions, access requests, or API key support, contact Sales Layer support or your account representative.