Conversions API
Any system that knows the outcome can now tell Apointo.
Native adapters cover the big booking platforms. The Conversions API covers everything else: your custom CRM, your internal sheet workflow, your client's homegrown system. One authenticated endpoint receives identity, attribution ids, and value. What comes back to your ad accounts is the same verified outcome every Apointo adapter produces.
Pages marked Planned are complete specifications written before the connector ships. They validate demand. Connectors with real delivery logs are marked Production or Beta.
If the outcome lives outside an adapter, it never reaches the ad
Clinics run bookings in systems no connector covers. The appointment happens, the ad platform never hears about it, and the campaign keeps optimizing on clicks.
One POST per outcome, one ledger for all of them
Send the outcome when it happens, with your own idempotency key. Apointo matches it to the original visit, applies consent rules, and delivers it to Google Ads exactly like a native integration would. Retractions work the same way in reverse.
- 01Your system confirms the outcome (booking, sale, stage change)
- 02One authenticated POST carries identity + attribution ids + value
- 03Apointo matches the visit, dedupes on your idempotency key
- 04The outcome enters the same ledger as native adapters
- 05Ad platforms receive it under the same consent rules
Request a scoped ingest token for your workspace.
POST each outcome with identity, attribution ids, value, and your idempotency key.
Re-sending the same key returns the same result; nothing duplicates.
Refunds and cancellations post as retraction events on the same record.
| From | Apointo |
|---|---|
| POST /v1/conversions { type: lead } | lead_captured |
| POST /v1/conversions { type: appointment_booked } | appointment_booked |
| POST /v1/conversions { type: appointment_attended } | appointment_attended |
| POST /v1/conversions { type: sale, value, currency } | sale_paid |
| POST /v1/conversions { type: refund } | refund_retraction |
Does this replace native adapters?
No. Adapters stay the zero-code path for covered platforms. The API is for systems that will never get an adapter.
What about consent and health data?
The same consent gates apply: ad-click ids are stripped without consent, and clinical detail never belongs in the payload. Identity is limited to matching fields.
When does this ship?
This page is the working specification. Early-access signups decide the build order.