COMUNICATION

This services sends automatic alerts about key process events (such as checkout, after-sales actions, and status changes). Operates on a push model, which requires clients to enable a webhook. Messages follow a simple, consistent format: a common section and an event-specific section, making them easier for clients to understand, integrate, and monitor.

All communications have the same playload; this is an example:

"notification_type": "snowdenAirline", // Template name
"action_required": false, // True or false depending on whether user action is required
"datetime": "2024-09-19T13:45:30.123Z", // Event datetime in GMT
"reservation_id": 12312300, // Reservation ID to which the notification corresponds
"products": [
		{"type": "FLIGHT", "id": "2312301"} // Product type and product ID
	]
"flow_id": "CAN-10976092", // after sales flow, if applies

"extra_info": { // This node is only sent in communications that require additional information; this is the only node that can contain any amount of data of different types.}

Mails Refund

The different types of communication are:

Refund confirmation manual coupon

This email is sent to inform that the points refund was successfully completed. The status can be checked at the /reservations endpoint. Refund timelines are stated in the documentation as a theoretical maximum.

Dynamic info: 72 hs
Extra_info: Nothing
Action_required: False

Refund Confirmation

This email confirms a monetary refund. The partner should take the amount and currency from additional_info and identify the product in the same payload. If the name and destination are needed, they can be retrieved from /reservations. Refund timelines are detailed in the documentation as a theoretical maximum.

Dynamic info: Amount, currency, payment to be paid, debit time, calcellation flow
Extra_info: Currency, amount and points
Action_required: False

Refund Information

This email indicates there was a failure with the payment method (e.g., PIX or bank details). The customer's banking information should be requested or updated, and they should be directed to contact the call center.

Dynamic info: Bank details
Extra_info: Nothing
Action_required: True

Refund rejected chargeback

This email informs that the refund is handled by the financial institution/processor (an external process). The payload includes all data except the amount and currency, which can be included if needed. It is important to inform the customer that the posting of funds depends on their bank and may be delayed according to the bank's timelines.

Dynamic info: Reservation number, request number, amount and currency, product and destination
Extra_info: Currency and amount
Action_required: False

Mails AfterSales

The different types of communication are:

Rescheduling minor eticket

The email informs that the flight underwent a minor change (e.g., a slight adjustment to time or flight number) that does not affect connections or legs. The e‑ticket is updated, and generally no action is required from the passenger other than reviewing the itinerary.

Dynamic info: New information about the altered flight (e.g., flight number, date, etc.)
Action_required: False

Rescheduling notification

The email communicates a major schedule change (significant changes to time, date, connection, or even airport).

Dynamic info: URL to recommended flights
Action_required: True

Rescheduling reminder

The email serves as a reminder that there is a schedule change.

Dynamic info: Recommended flights link, cancellation link
Action_required: True

eTicket PostSale

The email confirms that the flight has been issued/confirmed. It includes the e‑ticket (or a link to download it) and the final reservation and itinerary details.

Dynamic info: Trip details
Action_required: False

Thanks change flight

The email confirms that the change request was received. It states that availability and associated costs are being evaluated and that an update will be sent with the outcome or next steps.

Dynamic info: Fare, flight details
Action_required: False

Rejected credit card mid

The email indicates that the card was not authorized by the payment processor.

Dynamic info: URL to My Trips to change the payment method
Action_required: True

Begin cancel

The email confirms that the cancellation process has begun.

Dynamic info: "Product, destination and phone"
Action_required: False

Finalize cancel

The email confirms that the cancellation has been completed. It provides the refund status (if applicable), the estimated crediting timelines, and a summary of the reservation (amount, currency, legs).

Dynamic info: Passenger name
Action_required: False

Mails Checkout

The different types of communication are:

ffReservationDelayed

The email states that the reservation is delayed. The payment is being processed.

Dynamic info: Trip information, card ending (last 4 digits), installements and their composition and price and breakdown
Extra_info: Installments and their composition and price and breakdown
Action_required: False

ffFinishedOk

The email contains the trip information.

Dynamic info: Trip information and price and breakdown
Extra_info: Installments and their composition and price and breakdown
Action_required: False

Mails Trips

The different types of communication are:

Flight web checkin

The email says you can now check in on the website.

Dynamic info: Flight information and link to the airline
Extra_info: Link to the airline
Action_required: False

Mails Snowden

The different types of communication are:

Snowden airline

The idea is to forward, as-is, the HTML content that the airline sends in the JSON's extra_info field. The partner decides whether to forward this communication to customers or not. If the partner wants to block communications from a specific airline (while allowing others), they can identify the airline by checking the reservation in the /reservations endpoint. With that information, they can define the appropriate rule (forward, block, or customize the message) and act accordingly.

Dynamic info: Company HTML
Extra_info: Company HTML
Action_required: False