> ## Documentation Index
> Fetch the complete documentation index at: https://developers.cconnect.online/llms.txt
> Use this file to discover all available pages before exploring further.

# Idempotent requests

> Retry ticket creation and message submissions safely.

Every `POST /api/v1/tickets` request requires an `Idempotency-Key` header containing 1–128 visible ASCII characters. Choose a unique value from your source system, such as a CRM case identifier.

```http theme={null}
Idempotency-Key: crm-case-1042
```

The key belongs to your company and the ticket-creation operation. It is shared across credentials, so rotating a token does not duplicate a retried request. Another company can use the same key independently.

The server commits the ticket and its original response in one PostgreSQL transaction. Concurrent identical retries create one ticket and return that original `201` response. A replay includes `Idempotency-Replayed: true` and the ticket's original `Location` header.

Reusing the key with a different payload returns `409 idempotency_conflict`. Retries must preserve the same request, including custom-field object ordering. Use a new key when creating a different ticket.

Records are retained for the company's lifetime. Replaying an old creation returns its original response even if the ticket has since changed or been deleted. Retrieve the ticket separately to inspect its current state.

Ticket creation does not send an email or WhatsApp message. Send explicitly using the [messaging API](https://developers.cconnect.online/guides/send-messages.md).

## Message submissions

Both `POST /api/v1/messages` and `POST /api/v1/tickets/{id}/reply` require an `Idempotency-Key` with the same length and character rules. Their keys belong to your company and the specific operation, including the ticket ID for the reply route. Always retry the same URL and body.

Cconnect saves one encrypted queue entry for concurrent identical requests. Retries return the original `202` acceptance and message ID with `Idempotency-Replayed: true`. A different body with the same key returns `409 idempotency_conflict`. Switching between the two email routes creates a separate operation.

Use `GET /api/v1/messages/{id}` for current status. A replay returns the original acceptance, even if delivery later failed. Records are retained for your company's lifetime.

Cconnect submits each queued message once. If a network error or worker interruption leaves submission uncertain, the status becomes `delivery_unknown`. Cconnect does not automatically resubmit it. Provider callbacks can confirm a WhatsApp outcome later. Check the provider's logs before deliberately sending again with a new key; external providers cannot guarantee exactly-once delivery across a network failure.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.