Asynchronous mode is the default processing mode for all write operations. When you submit a request, Catena immediately returns aDocumentation Index
Fetch the complete documentation index at: https://docs.catenatelematics.com/llms.txt
Use this file to discover all available pages before exploring further.
202 Accepted response with a resource operation ID, then processes the request in the background with automatic retries and rate limiting.
Best for production workloads where you want to create or update multiple resources without waiting for each TSP response. Catena handles retries, rate limiting, and error recovery automatically.
How It Works
You submit a write request
Send a
POST or PATCH request to the Telematics API with is_sync=false (or omit the parameter, since async is the default).Catena returns immediately
You receive a
202 Accepted response containing a resource operation object with status: "pending". The id field is the operation tracking ID.Catena processes in the background
The request is queued and processed with automatic retries and rate limiting to respect TSP API limits.
Example: Sending a Message
Request
cURL
The
sender_id and recipient_id are Catena user IDs. Catena automatically resolves them to the TSP-specific identifiers (e.g., source_sender_id, source_recipient_id) before forwarding the request.Response (202 Accepted)
| Field | Description |
|---|---|
id | The resource operation ID. Use this to track the operation status. |
status | Always "pending" for async operations at creation time. |
resource | The type of resource being created (e.g., message, vehicle). |
operation_type | Either "create" or "update". |
resource_id | The Catena ID of the created resource. null until the operation succeeds. |
source_id | The TSP-side ID of the created resource. null until the operation succeeds. |
payload | The full payload sent to the TSP, including auto-resolved source IDs. |
logs | Empty initially. Populated with attempt logs if the operation fails. |
Receiving Results via Webhooks
To know whether an async operation succeeded or failed, subscribe to resource operation webhook events.Subscribe to Events
Create a webhook subscription for resource operation events:cURL
Using
resource_operation.* subscribes you to all three events: created, succeeded, and failed. You can also subscribe to individual events if you only need specific notifications.Success Webhook Payload
When the operation succeeds, theresource_operation.succeeded event includes the resource_id (Catena ID) and source_id (TSP ID) of the created resource:
Failure Webhook Payload
When the operation fails, the event includes error logs with details about what went wrong:| Error Type | Description |
|---|---|
auth | Authentication failed with the TSP (e.g., expired credentials) |
validation | The TSP rejected the payload (e.g., missing required fields) |
network | Network error connecting to the TSP |
tsp | The TSP returned an unexpected error |
Polling for Status
If you prefer not to use webhooks, you can poll the operation status using the Integrations API:cURL
cURL
When to Use Async Mode
Bulk operations
Bulk operations
When creating or updating many resources at once (e.g., sending messages to an entire fleet), async mode lets you fire requests rapidly without waiting for each TSP response.
Non-blocking workflows
Non-blocking workflows
When your application doesn’t need to wait for the TSP’s response to continue its workflow. For example, dispatching a message where delivery confirmation can arrive later.
Production workloads
Production workloads
Async mode provides built-in retries and rate limiting, making it more resilient for production use. Catena manages the complexity of TSP-specific rate limits and transient failures.
Next Steps
Sync Operations
Learn about synchronous mode for immediate TSP feedback.
Subscribe to Webhooks
Step-by-step guide on setting up webhook subscriptions.