Skip to main content

​
Vertical bundles: activation lifecycle semantics

The plugin marketplace documents what a bundle is and how to activate it. This page answers what happens when you activate more than once: overlapping bundles, re-activating the same bundle, version upgrades, and who can see the resulting checklist.

​
What a bundle is, and why draft-only

A bundle is a pre-wired industry pack: one draft compliance profile, a few draft campaign templates, a draft AI agent, an opt-in flow config, and a go-live checklist recorded on the profile. Activation provisions every piece as a draft and wires nothing to a carrier — the draft-only shape and the four shipped bundles are documented on the plugin marketplace page. Keep one thing in mind below: the activation record lives on the compliance profile it created. Every state this page describes — the bundle key, the version snapshot, the checklist — is anchored to a profile, and GET /api/v1/compliance/vertical-bundles/activations/:profileId reads it back from there.

​
Overlap semantics — two activations, overlapping use cases

Activation never merges with an existing profile. Each POST /api/v1/compliance/vertical-bundles/:key/activate call creates a new draft compliance profile, new draft campaigns, and a new draft agent, even when the bundle overlaps a profile you already have. The four bundles are use-case-disjoint (US 10DLC business messaging per vertical) — they provision resource drafts, not a message inventory. Duplicate profiles in overlapping verticals do not duplicate sends; they split the review burden. Operator rule: one activation per use case — click each bundle once. A second activation of the same bundle, or of two bundles covering the same traffic, produces two independent draft profiles with independent checklists, agents, and campaigns — and two journeys through carrier verification. Do not react to a failed review by re-activating: use the activate body overrides (brand_name, help_contact, country_code, countries) on the first call or edit the provisioned drafts; a re-call never rewrites the previous profile.

​
Idempotency — re-activating the same bundle duplicates, on purpose

The activate call is not idempotent. There is no dedupe check: activating healthcare_hipaa twice creates two draft profiles, two sets of draft campaigns, two draft agents, and two compliance.vertical_bundle.activated audit entries. Each duplicate is a full record, so the API side-affects of a retry are mechanical (double the drafts; nothing else resolves differently), but the operator cost is real — two checklists to review, two profiles in the verification queue. Build one-click activation as a once-per-bundle click in the dashboard, and gate any scripted call behind a read of GET /api/v1/compliance/vertical-bundles/activations/:profileId on the profile id you already recorded: if it returns a record, you have already activated. The read endpoint is keyed on the profile id, not the bundle key, so a duplicate pair returns two distinct records — there is no “latest activation wins” behavior and no auto-cleanup of an earlier copy.

​
Version N → N+1 — existing activations keep their version

Each activation record pins the bundle’s version at the moment of the call (version today: "1.0.0" for every shipped bundle). When Orbit ships a bundle update, the version field on shipped manifests advances; the version on your existing activation record does not change. An activation carries: An activation is a snapshot, not a subscription. The bundle update never rewrites a profile, campaign, or agent after the fact, and the old activation continues to resolve to the version it recorded.

​
Known remote changes

What an operator does when the catalogue ships a bump: The audit entry for every re-activation (compliance.vertical_bundle.activated) records the new version, so the org audit log shows the upgrade as a second activation, never as a silent rewrite.

​
Checklist data visibility — tenant-scoped, not user-scoped

The checklist the bundle provisions is tenant-scoped. The activation record (including every checklist step’s status) sits on the tenant’s compliance profile, and GET /api/v1/compliance/vertical-bundles/activations/:profileId returns that single shared record to any workspace role (owner, admin, developer, viewer). There is no per-owner checklist copy: if one teammate marks review_optin_copy done, everyone sees it done. Two consequences:
  • Review is a shared queue. Assign steps by step id (attach_documents, submit_profile, review_optin_copy, review_quiet_hours, the bundle-specific gate, review_campaign_copy) in your team’s tracker; the API checklist is the state of record, not a per-person to-do list.
  • Toggles are org-wide writes. Every PATCH writes one compliance.vertical_bundle.checklist_updated audit entry into the org audit log — the same log your compliance officer exports — stamped with the step id and the new status. Workforce visibility into who moved a step is exactly the org audit log; the API does not retain a separate per-user view.
(Owner, admin, or developer can toggle a step; viewers read the checklist but cannot change it.)