Member Provisioning (sales webhooks)

Enable a sales platform for this project. Returns the exact webhook_url to paste into the platform's webhook settings, and a setup hint per provider. The shared token or signing secret (Hotmart hottok, Stripe whsec_..., Dodo whsec_...) must be stored in the vault first (vault_store_secret) — pass its key name as secret_ref. Providers: hotmart, stripe (Stripe-Signature, events checkout.session.completed/async_payment_succeeded, invoice.paid grant; customer.subscription.deleted/updated to canceled|unpaid, full charge.refunded, charge.dispute.created revoke), dodo (Standard Webhooks preset), generic-webhook (any platform: you set verify, event_actions and paths in settings). Calling configure again updates status, secret_ref and settings.

Link a product or offer at the sales platform to a tenant group. A sale of this external_id then grants membership in tenant_code; refund/cancel revokes it. For Hotmart use the offer code (data.purchase.offer.code) or the numeric product id — both work. Upserts on (provider, external_id). Own checkout (provider internal): external_id is product:<id>, variant:<id> or sku:<sku> (a bare number is a product id; on an order line the variant wins over the sku, the sku over the product); file_ids are the gated files every paid line of it gives the buyer; tenant_code is the tenant of a new member, an existing member keeps theirs. Every provider: file_ids gives the buyer these gated files with each sale; a refund, cancellation or expiry takes them away again unless another active purchase gives the same file. Selling files one by one needs gated-files entitlement_mode asset.

Remove a product/offer mapping. Sales of that external_id are then audited as "unmapped" and never touch membership.

List all product/offer → tenant_code mappings for this project, optionally filtered by provider.

Audit trail of every received event: processed, duplicate, ignored, unmapped, signature_failed or error — with buyer email, action and detail. Your first stop when a member says "I paid but can't log in".

Test the entire chain without the real platform: injects a synthetic grant or revoke event through the same engine (idempotency, mapping, tenant lifecycle, audit). Verify the member appears/disappears and gated downloads open/close — then go live with confidence.

Run a server-side action after every processed purchase event: no browser, no polling. event "member.granted" (a verified sale created, reactivated or renewed a member) or "member.revoked" (refund, cancel, dispute or expiry). target_type "iapi_chain": ordered IAPI steps [{service, endpoint, input_template}] with {{fields.*}} from the event (buyer_email, tenant_code, external_id, subject_id, provider, lifecycle, metadata.KEY) and {{steps.N.result...}}, e.g. create a record, render a PDF, unlock gated files, send an email. target_type "flow_transition": moves the Flow Framework instance whose id is in the payment metadata (default metadata.instance_id, e.g. set on the Stripe Checkout Session) with flow.trigger as the internal actor, so an internal-only transition advances only after a verified payment; atomic and idempotent per subscription/payment. Runs once per subscription or payment by default (dedup "subject"; "event" = every received event). Pass action_id to change fields of an existing action. Test with simulate; results in list-deliveries.

Remove an action (set-action with active false only switches it off). Its past deliveries stay in list-deliveries.

All server-side actions of this project with their event, target, filters, dedup and effective retry policy.

No input parameters required.

What every action did: per delivery the status (pending, delivered, skipped, failed), attempts, error, result (flow: from and to state) and the event payload it ran with. Your first stop when a chain did not run or a flow did not move.

Queue one failed delivery again, e.g. after fixing the chain or the flow. A chain runs all its steps again from the first step.

The grant ledger: one row per paid subscription or payment with buyer email, mapped external_id, tenant_code, status (active, revoked, expired) and expires_at (UTC, when the mapping has duration_days). A member keeps access while at least one grant is active. Use it to answer "until when does this member have access?". Grants of a mapping with file_ids also list files: the gated files that purchase gave and whether that access is still active. Subject member:<id> (existing-member) is the baseline that keeps a member who had access before their first purchase.

Own checkout (provider internal): run one order through member provisioning now. For orders paid before you configured provider internal, to retry a line that failed, or to take an order's access away by hand (action revoke). Idempotent: lines that already gave access stay as they are. dry_run shows per order line which mapping applies and what would happen, without changing anything. Returns per line: status (processed, duplicate, unmapped, ignored, error), detail and the gated files given or taken away.