The content of this page was extracted in full from Send points accumulation | Developers | LATAM Pass .
Send points accumulation
POST
The example below contains the minimum required fields to perform a points accumulation. See the following link for complete details of the interface: Swagger Create Accrual POST .
Below is an example CURL:
Functional explanation of each field
- partner.id → the partner's registration ID in the Latam Pass system. This content is provided by the Latam Pass sales team.
- member.ffn → Frequent Flyer Number. In BR, it is the same as the CPF. In CL, it is the same as the RUT.
- member.email → member's email
- partnerAccrualId → Systemic ID of the partner. Can send an internal control ID. Limit 50 characters.
- partnerTransactionId → ID used for billing. This data is key for financial reconciliation and can be the same ID sent in the partnerAccrualId field. The most important thing is that the partner has control of this field to perform financial reconciliation when Latam Pass generates the invoice for payment. Limit 50 characters.
- partnerOriginDate → date and time of the accrual request in the partner's system, corresponding to the date and time of the customer's activity with the partner.
- description → free field. Suggested submission: Accumulation of points for product XYZ.
- points → amount of points to accumulate.
- productId → Product registration ID linked to partner.id. This content is provided by the Latam Pass sales team.
- interfaceId → fixed 3.
In a successful case, you will receive the following JSON return.
We always use the ID and correlationId to analyze the entire accumulation flow. It is important to save the ID returned above as it is proof of acceptance on the LatamPass side.
Duplicity rule
Accumulations have mandatory data and some of them are used in duplication validation.
Below is the dataset used in this process:
- ffn
- partner_id
- partner_transaction_id
- partner_origin_date
- points
If a transaction is found in our DB with the same data, it will be indicated as a duplicate in the request response. If not, the transaction continues the processing flow.
This point is important because if a shipment is made with different data, it will be considered a new transaction.
Sending dates
Accumulations are credited using the date sent by the partner and it is used as a parameter for any action that depends on dates. Example: if we have a campaign to award points bonuses, the date to validate whether it is eligible for the bonus is the date received by the partner (original date of the accumulation request).
In this sense, we request that you send the dates as per the examples below:
The date must be sent in the ISO-8601 standard, as this standard allows us to preserve the timezone.
CORRECT SUBMISSION FORMAT
With Timezone: '1997-07-16T19:20:30-03:00'
This point is not an impediment to accumulation, therefore, if the date is sent without the timezone we will follow the internal conversion rules.
Collection Postman
The following link contains the Postman project for Sandbox testing.