Skip to main content

​
Compliance plugin marketplace

Settings → Compliance → Marketplace is the browse page for every compliance pack your workspace can mount. It serves two kinds of packs, and this page owns one of them:

Evidence-export packs (SOC 2, ISO 27001, GDPR, HIPAA)

One-click evidence binders for auditors and buyers — formats, signed downloads, and role gates are documented on the evidence-binder page.
The other kind — and the focus below — is activation bundles: pre-wired industry packs that provision everything a regulated vertical needs in a single call, as drafts. The four shipped bundles are HIPAA healthcare, fintech KYC, e-commerce, and PCI payment collection.

​
Bundle lifecycle — draft, upgrade, retire

Every activation lives in one of three states, and the state is nothing more exotic than the lifecycle of ordinary draft resources:
  1. Draft (active) — the bundle’s profile, campaigns, and agent exist as drafts; the checklist on the profile tracks the go-live reviews. Most activations sit here longest.
  2. Upgradeable — Orbit ships a new bundle version; your activation keeps its version snapshot. Upgrading means retiring the snapshot voluntarily and re-activating (below), never an in-place rewrite.
  3. Retired — you deleted the provisioned drafts. The audit entry from activation remains; the checklist record is gone with the profile.
Upgrading across versions. The version field in the manifest is informational until the catalogue ships a bump, and then it pins exactly one thing: what a fresh activation would provision today. Your existing activation records the version it was created at and never moves. There is no in-place upgrade path — a revision never rewrites a profile, campaign, or agent after the fact. To move to the new version, retire the snapshot (see Retiring a bundle below) and re-activate. The activation-semantics page shows the manifest-vs-snapshot comparison table field by field.

​
Cost and quota — what activation actually consumes

Nothing is billed on activate. The call provisions drafts, and drafts cannot send — so the only metered surface a bundle ever touches is its AI agent, and only once you take it live. Deleting the drafts (or never going live) restores the full entitlement. A dormant bundle costs nothing, indefinitely — the only real cost of leaving one around is the review burden of one more checklist in your compliance queue.

​
Retiring a bundle — deactivation, safely

There is no deactivate endpoint, on purpose: the bundle only ever created drafts, and a draft is a normal resource. Deactivation means deleting the drafts the bundle created, and it never harms anything you built afterward. Which ids to retire. The activation record (GET /api/v1/compliance/vertical-bundles/activations/:profileId) carries the exact ids the bundle created: the complianceProfileId, every campaign id in campaigns[], and the agentId. Delete those three classes of drafts through their normal management surfaces — nothing is orphaned and nothing becomes read-only, because the bundle never touched anything outside those drafts. Before you delete, check for shared edits. The bundle’s drafts are ordinary resources, so anything your team layered on after activation — a hand-edited campaign body, a published agent that started as the bundle draft, an opt-in flow you re-pointed — disappears with them. If a resource has drifted from its seeded shape, export or copy it out first. What survives on purpose. Deleting the drafts does not delete the audit trail. The compliance.vertical_bundle.activated entry stays in the org audit log (resource: vertical_bundle on the retired profile id) together with every checklist toggle, so the record that the review queue existed is preserved exactly as an auditor expects. What the checklist was doing. The checklist lives on the profile, so it is never orphaned — it goes with the profile. If the bundle revision shipped something material (a new checklist gate, a new campaign), re-activate after deleting to mount the new shape; if nothing has changed, a re-activate just produces a fresh snapshot of the same bundle.

​
What a bundle activation provisions

Activating a bundle creates five things in one call:
  1. A draft compliance profile for the vertical (a US 10DLC business profile).
  2. Four to five draft campaign templates — the bundle’s seeded message copy, ready to review.
  3. A vertical-tuned AI agent (created as a draft — for example a patient-intake assistant or an order-support assistant).
  4. An opt-in flow configuration capturing the seeded confirmation copy, brand name, and help contact.
  5. An in-product go-live checklist recorded on the compliance profile.
Nothing goes live on activation. The draft-only shape is deliberate: activation never wires a carrier and never places a send. Each created campaign is titled <brand> — <template> so you can tell bundle-provisioned campaigns from your own.

​
Bundle catalogue

List summaries (name, vertical, campaign and checklist-step counts) with GET /api/v1/compliance/vertical-bundles, then fetch the full manifest for a key with GET /api/v1/compliance/vertical-bundles/:key. The manifest returns the complete definition below — preview it before you activate anything.

​
Healthcare — HIPAA patient messaging (healthcare_hipaa)

Patient appointment, refill, and follow-up messaging that keeps PHI out of plain SMS.
  • Profile: HIPAA Patient Messaging
  • Campaigns (4): appointment reminder, prescription-refill ready, post-visit follow-up, billing notice — all routed to a secure link rather than carrying PHI
  • Agent: Patient Intake Assistant (chatbot) — applies the minimum-necessary principle, directs anything clinical to the secure portal or staff, and never gives medical advice
  • Extra checklist gate: sign a Business Associate Agreement (BAA) under Compliance → BAA

​
Fintech — KYC onboarding & account alerts (fintech_kyc)

  • Profile: Fintech KYC & Account Alerts
  • Campaigns (5): KYC verification reminder, account-onboarding welcome, transaction alert, statement ready, fraud alert
  • Agent: Onboarding & KYC Support Assistant (chatbot) — never requests full ID numbers, card numbers, passwords, or one-time passcodes, and escalates suspected fraud
  • Extra checklist gate: confirm the transactional-vs-marketing consent split — alerts are transactional; promotions need explicit marketing consent

​
E-commerce — order lifecycle & re-engagement (ecommerce_transactional)

  • Profile: E-commerce Order & Marketing Messaging
  • Campaigns (5): order confirmation, shipping update, cart abandonment, review request, promotional offer
  • Agent: Order Support Assistant (chatbot) — handles order status, returns, and product questions without ever taking payment details
  • Extra checklist gate: separate marketing consent from order updates — the promotional campaign must only target marketing-consented contacts

​
Payments & collections — PCI-safe collection (pci_payment_collection)

Invoice, payment-link, and dunning messaging that never carries card data.
  • Profile: PCI-Safe Payment Collection
  • Campaigns (4): payment-link request, invoice due reminder, payment confirmation, failed-payment retry — every one points to a secure hosted payment link
  • Agent: Billing & Payments Assistant (chatbot) — never accepts card or bank details in chat; if a customer sends them anyway, the agent declines and re-sends the secure payment link
  • Extra checklist gate: confirm your hosted payment page is PCI-compliant

​
Activating a bundle

The body is optional; each field overrides the seeded copy: The response is 201 with the activation record: the bundle key and version, the complianceProfileId, the provisioned campaign ids, the agentId, the resolved opt-in config, and the checklist with each step’s status.

​
Go-live checklist semantics

Every bundle ships a checklist with two step kinds:
  • auto steps — completed by the activation call itself, stamped done with a completion time in the initial record.
  • manual steps — start pending and track the tenant-side reviews before go-live: attach the profile’s required documents, submit the profile for verification, review the opt-in confirmation copy, confirm the quiet-hours window, clear the bundle-specific gate (BAA, consent split, or hosted payment page), and approve the campaign copy.
Steps form an ordered review queue. You may check them off in any order, but the intended progression is documents → profile submission → consent and copy reviews → final campaign approval. A step marked done keeps its first completion time; setting it back to pending clears the timestamp, so the audit trail reflects the current review state. What “draft until go-live” gates: the checklist is an in-product tracker, not a send gate — it never blocks an API call. The actual gate is the draft state of every provisioned resource. Campaigns stay draft and unscheduled until you approve them, the AI agent stays in draft status, and the compliance profile must clear verification before anything sends through it. The checklist exists so your team can prove each of those reviews happened. Read back an activation with GET /api/v1/compliance/vertical-bundles/activations/:profileId (the complianceProfileId from the activate call), and toggle a step with:
The response returns the full updated activation record, so the dashboard can re-render from one call.

​
Limits and access control

  • Catalogue size — four bundles ship today; each activation call mounts one bundle.
  • Scale guardrails — campaign templates are capped at five per bundle; the countries override accepts at most 50 codes.
  • Concurrency — there is no scheduled-activation quota; the standard authenticated write rate limit applies.
  • Roles — reading the catalogue, manifests, and activation state requires any workspace role (owner, admin, developer, or viewer). Activating a bundle or toggling a checklist step requires owner, admin, or developer.
  • Audit trail — every activation writes a compliance.vertical_bundle.activated audit entry with the bundle key, version, campaign count, and agent id; every checklist toggle writes a compliance.vertical_bundle.checklist_updated entry with the step id and new status.
  • Tenant-owned — the platform never requires a bundle; you decide which packs your workspace mounts, and a dormant bundle sits as drafts indefinitely.

​
FAQ

Is activation idempotent? No — the activate call is deliberately not idempotent, and there is no dedupe check. Retrying the call creates a second full set of drafts (profile, campaigns, agent) and a second audit entry, so gate any scripted activation behind a read of the profile id you already recorded. The full overlap and re-activation semantics are on the activation-semantics page. Can I activate the same bundle twice? You can, and the result duplicates on purpose — two independent draft profiles, two checklists, two verification journeys. That path is intentional for genuinely parallel setups (two brands, two regions); for anything else, retire the surplus drafts and keep one. The decision table on the semantics page maps duplicate-vs-snapshot: a re-activation never rewrites the first snapshot, and upgrading versions means retire-then-re-activate, never an in-place upgrade. What role can activate a bundle? Owner, admin, or developer — activation and checklist toggles are write calls, so they require one of those three roles. Viewers can read the catalogue, manifests, and activation state but cannot activate or toggle a step. See the access-control list under Limits and access control above.