CRM / ERP Integration
How the flow works
The CRM/ERP creates the contract
The CRM/ERP registers the sale and sends value, beneficiaries, number of installments and due dates.
Play2sell issues the boleto
Play2sell PAY originates the sale and emits a BOLEPIX boleto per installment to the consumer.
Play2sell returns the boleto to the CRM/ERP
The issued boleto (digitable line) is written back to the reservation in your CRM/ERP.
Consumer pays → Play2sell informs the CRM/ERP
On payment confirmation, Play2sell writes the paid status back to your CRM/ERP.
The CRM/ERP registers the deed → release
When the sale is deeded, the commission is released and split to beneficiaries.
Setup (per tenant)
Configure credentials
Add your CRM/ERP credentials (
domain, email, token) under Integrations → CRM/ERP. They are stored per tenant and never shared.Map statuses to actions
Configure the status map so Play2sell knows which CRM/ERP status means sold, deeded, or rescinded. This varies per CRM/ERP instance, so it must be set explicitly.
| Action | Meaning | Drives |
|---|---|---|
| Sold | Reservation sold | Sale origination + boleto |
| Deeded | Deed registered | Commission release + split |
| Rescinded | Contract undone | Refund to consumer |
How sync works
CRM/ERP webhooks are typically thin (they carry only an identifier). Play2sell classifies the event by status, enqueues it, and pulls the full record back from the CRM/ERP API before acting — so a forged webhook cannot inject data.| Property | Behavior |
|---|---|
| Idempotency | Each contract maps to a stable key derived from the CRM/ERP reservation id; re-delivery never duplicates a sale. |
| Ordering | If a deed event arrives before origination completes, it is deferred and retried automatically. |
| Identity | Buyers and beneficiaries are resolved by CPF/CNPJ (document), never by email. |
| Write-backs | Boleto created and boleto paid are delivered to the CRM/ERP with retry until acknowledged. |
Error contract
Non-2xx responses follow{ code, message, hint? }. A 4xx is a rejection (e.g., misconfiguration — fix and retry); a 5xx is a transient error (retried automatically).