Zintara API rate-limit handling: bound retries without inventing a quota

Define the decision

The reviewed application does not establish a universal documented API-key rate-limit contract. A deployment proxy or upstream service can still impose limits. Do not hard-code a supposed Zintara quota based on an unrelated service.

Work through the procedure

1. Begin with low concurrency and monitor actual status codes.
2. If a 429 response supplies Retry-After, honor its valid delay within your job policy.
3. Use bounded backoff with jitter for appropriate temporary failures.
4. Separate safe reads from writes whose outcome may already have occurred.
5. Escalate recurring refusal with sanitized timing and request counts.

Worked example

The following is a synthetic example for this procedure, not a customer result or performance benchmark.

GET list request → 429 with a delay → bounded later retry
POST create request → network timeout after upload → outcome unknown
Different recovery: read or reconcile state before repeating the write

Read the result

A rate-limit handler should reduce pressure, not multiply workers. Retry exhaustion should remain visible with enough context for the owner to distinguish a quota, outage or malformed request.

Check before moving on

1. Never log the Authorization header.
2. Cap retry count and total elapsed time.

Limits and next action

This is a consumer design pattern, not a throughput promise. Verify deployment-specific limits with the operator before scheduling a high-volume synchronization.

Source: Zintara implementation and product context