Skip to main content
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.
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.

​
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.