API
Delivery & Retry Policy
Understand delivery timeouts, exponential backoff, jitter, retry exhaustion, and manual retry triggers.
Delivery Behavior & Timeouts
- HTTP Method: POST
- Request Timeout: 15 seconds connection & total socket timeout.
- Payload Envelope: Standard JSON schema with
id,type,created_at,project_id, anddata.
- Response Handling: HTTP 2xx statuses (200-299) are marked as delivered.
Retry Schedule & Backoff
When a destination fails with a network timeout, HTTP 408, 429, or 5xx error, Asiyst schedules up to 5 attempts with exponential backoff and jitter:
| Attempt | Delay | Description |
|---|---|---|
| Attempt 1 | Immediate | First real-time dispatch |
| Attempt 2 | ~1 - 2 seconds | 1s base + jitter |
| Attempt 3 | ~2 - 3 seconds | 2s base + jitter |
| Attempt 4 | ~4 - 5 seconds | 4s base + jitter |
| Attempt 5 | ~8 - 9 seconds | Final automatic attempt |
Retryable vs Non-Retryable Status Codes
- Retryable: 408 (Request Timeout), 429 (Too Many Requests), 500, 502, 503, 504, and TCP connection resets.
- Non-retryable: 400 (Bad Request), 401 (Unauthorized), 403 (Forbidden), 404 (Not Found), 405 (Method Not Allowed). These fail immediately without exhausting further retries.
Manual Delivery Retries
If an endpoint was temporarily down, you can manually trigger a retry in the Delivery Logs tab. Manual retries use the identical signing keys and delivery pipeline as automated deliveries.