Step 12 — DPA and plan
A signature and a payment: the two steps that stay human however good your agent is.
Sending a customer's conversion to Meta is a disclosure to a third party. Atribu will not do it on your behalf without a Data Processing Agreement you have accepted, and the plan you are on decides how many profiles you can run.
Neither is a step an agent can complete for you: a signature forged on a human's behalf is not a signature, and a payment is a payment.
Accept the DPA
Settings → Compliance, or the prompt inside Conversion Sync. The click-wrap requires scrolling to the end before Accept becomes active, and records who accepted, when, from where, and which document version.
If you handle health-adjacent data, you want the BAA as well — Healthcare onboarding is the sequence for that, and it changes what may be exported at all.
Pick a plan
Settings → Billing. Free is $0 with one active ad account. Growth and
Agency are self-serve Stripe checkouts; Enterprise talks to us first.
Read both states — this much works today:
curl -H "Authorization: Bearer atb_live_YOUR_KEY" \
"https://api.atribu.app/api/v1/conversion-sync/legal"curl -H "Authorization: Bearer atb_live_YOUR_KEY" \
"https://api.atribu.app/api/v1/workspaces/{workspaceId}/subscription"Readiness reports both as steps with a handoff_kind — sign_dpa and
checkout — which is the API telling you plainly: this one is a person's.
Today, hand your user a link to Settings → Compliance or Settings → Billing and poll the two reads above until they change.
Both are hand-offs now, so neither is a dead end for an agent:
curl -sX POST https://api.atribu.app/api/v1/legal/dpa/handoff \
-H "Authorization: Bearer atb_live_YOUR_KEY" \
-H "Content-Type: application/json" -d '{}'A session-less URL rendering the same click-wrap, recording the same signer
identity, completing the hand-off when they accept. /baa is the combined
DPA + HIPAA BAA. A hand-off for an already-accepted DPA answers completed
immediately — never a second signature. POST /api/v1/legal/dpa/accept is the
signed-in owner/admin path, so acceptance has one write however it is reached.
Full detail: Legal.
curl -sX POST https://api.atribu.app/api/v1/workspaces/{workspaceId}/checkout-session \
-H "Authorization: Bearer atb_live_YOUR_KEY" \
-H "Content-Type: application/json" -d '{"plan":"growth"}'A checkout hand-off wrapping a Stripe Checkout URL; the Stripe webhook
completes it. Minting for a workspace already on that plan answers completed
with no_change. Full detail: Billing.
Over MCP
sign_dpa and start_plan_upgrade mint the same two hand-offs (#1058). Poll
either with get_handoff.
A growth or agency workspace gets its checkout at creation
POST /api/v1/workspaces with plan: "growth" or "agency" returns the
checkout hand-off in the checkout field of the create response — so an agent
that knows which plan it wants never has to mint one separately. See
Workspaces & profiles.
Do not block on this to keep working
A profile whose DPA is unsigned still tracks, still attributes and still
reports. What it will not do is export to Meta. A profile at its plan's
active_profiles limit keeps working too — what is refused is adding
another one.
What each one gates
| unsigned DPA | plan limit reached | |
|---|---|---|
| tracking, attribution, dashboards | works | works |
| this profile | works | works |
| exporting to Meta / Google | blocked | works |
| creating another profile | works | blocked |