Callbacks
Introduction to RCS Callbacks
Callbacks are real-time notifications sent to your system whenever an event related to RCS messages occurs. They allow full monitoring of the message lifecycle, from sending to recipient interactions.
Communication Flow
- Message Trigger → Your system sends the message via the API
- Eventos RCS → The gateway processes and sends the message
- Callbacks → Your webhook receives real-time updates
Main Use Cases
- Delivery and read receipt confirmation, and numbers without RCS support
- Tracking interactions (clicks, responses)
- Error and exception handling
- Collecting metrics and analytics
Callback Parameters
All callbacks share a common structure with the following parameters:
| Parâmetro | Tipo | Descrição |
|---|---|---|
reference | String | The unique ID parameter, which remains unchanged regardless of internal (send) or external (responses, clicks, and calls) events. |
campaign_name | String | The name of the RCS campaign. |
event_id | String | This is also an ID parameter, but it changes when there is an external event (e.g., button clicks or text responses). Before that, it remains the same until the message is marked as read. (Typically used for tracking clicks and customer responses). |
direction | String | outbound (sending) or inbound (receiving) |
session_id | String | The session ID (null for basic or single-type messages) |
user_id | String | The recipient’s phone number |
timestamp | String | Date/time of the event (ISO 8601) |
channel | String | The channel from which your message was sent. If the phone supports RCS, the channel will be RCS; if the phone doesn’t support it, the channel will be SMS (if fallback is configured). |
type | String | Event identifier, used to identify what was sent and its status. This field is filled based on the direction. In the first case, the type of RCS being sent will appear. In the second case, it will indicate whether the message was delivered, read, or if the user interacted with it, etc. |
message | Object | This field is filled in 3 situations: 1) First callback return, showing the message sent. 2) The message is filled with the customer’s message or the action they took. 3) When we encounter any of the “Exception” cases for fallback sending or errors sent by Google. If it doesn’t fit into any of these cases, it always returns NULL. |
vars | Object | If the variable parameters were filled in your send request, the callback return will contain those variables. |
status | String | Only present in cases of duplication blocking. It provides information about the block. |
Webhook Events
Text
Video
Image
RichCard
Carousel
Status
DELIVERED
When type: delivered, it means that the message has been sent to the device.
READ
When type: read, it means that the message has been read.
PREPAID_BLOCKED
When type: PREPAID_BLOCKED means that the sending was blocked due to lack of credits. The message may be “Limite de créditos do cliente atingido” which is when the customer has no credits, or “Limite de créditos da conta atingido accountId” which is when the account used in the trigger that is linked to the customer has no credits. The account ID will be shown in accountId.
suggestionResponse
When type: suggestionResponse, it means that the user interacted with the message.
EXCEPTION
Whenever we encounter an Exception, the message property will display one of these responses:
- Request failed with status code 401: Failed to fetch the authentication token.
- Request failed with status code 403: Device does not support RCS.
- Request failed with status code 404: Device does not support RCS.
ERROR
Whenever we encounter an Error, the message property will display one of these responses:
- Request failed with status code 502: Bad Gateway.
- Request failed with status code 503: Service Unavailable
Response
TEXT
IMAGE
VIDEO
LOCATION
Timeout
The webhook will attempt to be sent to the receiver for up to 10 seconds after an event occurs. If the delivery is unsuccessful, it will proceed to the next retry attempt.
Send Attempt
If the webhook fails (due to a timeout, receiver error, or if the receiver’s response is not an HTTP 200 code), it will be retried up to 10 times. The attempts are made at the following intervals:
- 1st attempt: 10 seconds;
- 2nd attempt: 30 seconds;
- 3rd attempt: 2 minutes;
- 4th attempt: 10 minutes;
- 5th attempt: 30 minutes;
- 6th attempt: 1 hour;
- 7th attempt: 3 hours;
- 8th attempt: 6 hours;
- 9th attempt: 12 hours;
- 10th attempt: 1 day.
Endpoint Requirements
-
Must return HTTP 200 for confirmation
-
Maximum response time: 10 seconds
-
Must handle duplicate messages (idempotency)