Developer guide
Compliance Kit
Claim scans, required disclosures, external sites, status data under a BAA, and no ad-platform forwarding.
Open the Developer CenterNever send patient information to a sandbox key.
On this deployment: External-site registry and scan receipts: Not built yet · Webhooks to your receivers: Sandbox only · Headless Connect API: Not available in this environment
- External-site registry and scan receipts: Not built yet. What runs now: Ad hoc claim scans of copy through the sandbox API.
- Webhooks to your receivers: Sandbox only. What runs now: Signing, retries (19 attempts over at least about 74 hours; every 4xx but 410 retried, 410 disables the receiver), dead letters, replay and delivery receipts against the in-process synthetic receiver (.demo.invalid) on synthetic deployments; a self-serve developer connection for brands with no partner integration; and, built but not yet exercised on a deployed sandbox, sandbox delivery of synthetic events to a developer's own https receiver while the developer_webhooks sandbox rail is open; and, written and unit-tested but with its migration not yet applied and its pgTAP suite not yet run, lifecycle event producers with refs-only payloads carrying the enrollment id and externalReference (enrollment.created, subscription.created, subscription.canceled, payment.failed, and enrollment.status_changed produced only under the brand-to-entity BAA and downstream-systems attestation and re-checked at every send).
- Headless Connect API: Not available in this environment. What runs now: Sandbox-key calls to /api/v1 on the nonproduction deployment with synthetic data: claims scan, formulary, rulebook, the sandbox order preview, delivery reads and replay, and the MCP endpoint, on a deployment whose database has the 20261101090000-range migrations applied (a hard deploy-order dependency the merge gate enforces; ahead of them the rulebook, claims scan, MCP and replay answer 503).
Scan your copy before you publish it
POST /v1/claims/scan checks copy against the same active rulebook that gates publication inside the platform, for the channel you name. Pass the required disclosures' ids and digests and it reports each as present or missing. Run it in CI and publish only on a pass.
Show the required disclosures verbatim
GET /v1/catalog/{brand}/disclosures returns every block a hosted page would show: each program's approved disclosure and cancellation terms, its regulatory standing, the emergency notice and the legal documents to link. Render the text exactly, keep the digest, and refresh when the digest changes.
Register and attest your sites
Register each site that sells for your brand, prove you control it, and have your tenant owner sign two attestations with two-step verification:
- Site attestation: the site collects no health information, carries no pixels on hand-off or condition pages, shows the required disclosures and has its copy scanned before publish.
- Downstream-systems attestation: every webhook receiver, and every CRM, email and support system it feeds, is covered by a business associate agreement, and no Ambition data goes to an ad platform.
Status data needs a business associate agreement
An enrollment's coarse status (in_review, needs_info, approved, not_approved and the intake states) is treated as protected health information. Your brand receives it, by API or by enrollment.status_changed, only while all three hold:
- the brand-to-entity business associate agreement is recorded and in force;
- your downstream-systems attestation is signed and in force for that plane;
- the person who created the key, or registered the receiver, holds minimum-necessary patient access.
Without them each of those states reads in_progress and no status event is produced. With only the agreement you still get created, account_verified and canceled. The conditions are checked again at every read and every send, so a lapsed agreement stops the next delivery.
Never forward Ambition data to ad platforms
Do not send any Ambition-derived data, including an enrollment id, a status or the fact that an event arrived, to an ad-platform conversion API or audience builder: Meta Conversions API, Google Enhanced Conversions, TikTok Events API or similar. This is part of the downstream-systems attestation, and breaking it is a breach of that attestation.
A brand may register up to 5 receivers per connection and plane; each one is covered by the attestation.