Zapier

An instant trigger for every webhook event, an action for every write and a search for every read, on the Subscriby Zapier app.

The Subscriby Zapier app exposes 183 instant triggers, 115 write actions and 93 searches — one trigger per webhook event, an action for every write and a search for every read on the live api.subscriby.net/v1 surface. Every count on this page is generated from the app's source.

Install

The Subscriby Zapier integration is currently invite-only and is not yet publicly listed in the Zapier App Directory. To request access, contact the Subscriby team. Once you receive an invite link, click it to connect your account. During the OAuth-less connection step Zapier asks for an API token — mint one at app.subscriby.net/settings/tokens with the abilities listed per trigger / action below.

The Subscriby Zapier app is undergoing testing and validation before its public Zapier listing. Access is invite-only during this period.

Production tokens start with sbt_live_; non-production (staging, local) tokens start with sbt_test_. Both work — Subscriby rejects tokens from the wrong environment automatically.

Triggers

Grouped by family. Every trigger uses the REST Hook pattern: on Zap activation Zapier calls POST /v1/webhook-subscriptions, on deactivation it calls the matching DELETE. All triggers additionally implement a polling fallback (performList) against /v1/webhook-events so the Zap editor can show a sample even before any live event has fired. One trigger is polling only: notification_received reads /v1/me/notifications?unread=1 and fires once per new entry of your notification centre, because the notification centre raises no webhook of its own.

183 instant triggers, one per event, grouped by family.

Every trigger additionally requires webhook-endpoint:manage on the token so Zapier can create and delete the underlying webhook endpoints.

How triggers work

You pick a trigger in Zapier

Example: New Subscription. Zapier's performSubscribe calls:

POST https://api.subscriby.net/v1/webhook-subscriptions
Authorization: Bearer sbt_live_<id>_<secret>
Idempotency-Key: <zap-scoped-uuid>
Content-Type: application/json

{
  "name": "Zapier — New Subscription",
  "url": "<zapier-inbound-url>",
  "events": ["subscription.created"]
}

Subscriby registers the endpoint

The response includes { data: { id }, secret }. Zapier stores both — the secret powers SB-Signature verification on every inbound event.

Event fires inside Subscriby

Any matching event enqueues a delivery to the Zapier inbound URL. Zapier verifies the signature, decodes the envelope, and hands data.* to your Zap.

You turn the Zap off

Zapier calls DELETE /v1/webhook-subscriptions/{id} with a matching idempotency key. The endpoint is removed server-side.

Actions

All writes auto-inject a fresh Idempotency-Key header per call — retries are safe.

115 actions, grouped by what they act on. Each line names the Zapier key, the label you pick in the editor, the route it calls and the token ability that route needs.

Access Codes (2)

  • bulk_generate_access_codes — Bulk Generate Access Codes — POST /v1/projects/{project}/plans/{plan}/access-codes/bulk-generate · project-access-code:create Queue a bulk access-code generation batch for a plan. Returns immediately with a preview of the worst-case overage ("if every code is redeemed, this is what it would bill"). Stripe metered overage fires on redemption, not generation.
  • delete_access_code — Delete Access Code — DELETE /v1/projects/{project}/plans/{plan}/access-codes/{accessCode} · project-access-code:delete Delete (invalidate) a specific access code on a plan. Redeemed codes remain locked — only unredeemed codes can be removed.

Account (4)

  • accept_partner_terms — Accept Partner Terms — POST /v1/me/partner/terms/accept · account:write Record that you accept the Partner Program Terms as they stand today, which every payout rail requires; running it again after the terms change is the same call. Refused while your application is under review or was declined.
  • mark_all_notifications_read — Mark All Notifications Read — POST /v1/me/notifications/read-all · account:write Mark every unread entry of your notification centre as read in one call and learn how many were marked. Running it again marks nothing and answers 0.
  • mark_notification_read — Mark Notification Read — POST /v1/me/notifications/{notification}/read · account:write Mark one entry of your notification centre as read, so the dashboard bell stops counting it. An entry already read keeps its first read time.
  • update_partner_payout_details — Update Partner Payout Details — PUT /v1/me/partner/payout-details · account:write Write how you are paid as a partner: the rail, what it pays to (the PayPal email, the USDT wallet, or the bank account for Wise and Remitly) and the tax declaration every cash rail needs. Only the destination the chosen rail uses is kept, encrypted; nothing ever returns it. A rail cannot be saved until you have accepted the Partner Program Terms: tick Accept Terms here or run Accept Partner Terms first.

Broadcasts (1)

  • broadcast_message — Broadcast Message — POST /v1/projects/{project}/broadcasts · broadcast:send Send a Telegram message to a segment of a project’s members. The send is queued and runs in the background — watch the Broadcast Completed trigger for the sent/failed tallies. Cannot be recalled once sent.

Coupons (5)

  • activate_coupon — Activate Coupon — POST /v1/projects/{project}/coupons/{coupon}/activate · project-coupon:update Switch a coupon on so it can be redeemed again. Raises Coupon Activated rather than Coupon Updated. Active is not the same as redeemable — a code outside its window or fully claimed stays unredeemable while on.
  • create_coupon — Create Coupon — POST /v1/projects/{project}/coupons · project-coupon:create Issue a discount code on a project. A coupon is one code any number of subscribers can redeem for money off at checkout — not an access code, which is one code for one person and grants access outright. The discount applies to the first payment only. Requires the Coupons Addon or a Growth plan.
  • deactivate_coupon — Deactivate Coupon — POST /v1/projects/{project}/coupons/{coupon}/deactivate · project-coupon:update Switch a coupon off. The safe way to retire a code: new redemptions stop immediately and every redemption already recorded is kept. A checkout already in flight still completes, so expect a late Coupon Redeemed shortly after. Raises Coupon Deactivated.
  • delete_coupon — Delete Coupon — DELETE /v1/projects/{project}/coupons/{coupon} · project-coupon:delete Permanently delete a coupon and its redemption history. Refused (422) while any checkout has this code quoted to a payment provider — deactivate instead, which stops new redemptions and keeps the history.
  • update_coupon — Update Coupon — PATCH /v1/projects/{project}/coupons/{coupon} · project-coupon:update Partial-update a coupon. Only the fields you fill in change; blank fields keep their value. Changes are not retroactive — subscribers who already redeemed keep what they paid. Raising the cap on an exhausted code makes it redeemable again; lowering it below the count claws nothing back.

Creator Tasks (1)

  • complete_creator_task — Complete Creator Task — POST /v1/projects/{project}/creator-tasks/{task}/complete · project-subscription:update Mark a hand-arranged perk as handed over. The task is recorded done by the token's user, the subscriber's grant is issued, and Creator Task Completed then Member Added to Resource fire for it. A task already done, or one whose purchase has ended, is refused.

Groups (4)

  • create_group — Create Group — POST /v1/groups · group:create Create a permission group inside a team. A role is what one collaborator is; a group is a named bundle several people can be put into. Membership is set separately with Sync Group Members. Growth-tier feature.
  • delete_group — Delete Group — DELETE /v1/groups/{group} · group:delete Delete a permission group. Everyone in it loses whatever the group granted, though they stay in the team.
  • sync_group_members — Sync Group Members — PUT /v1/groups/{group}/members · group:update Replace a group's membership with the supplied user IDs. This is a SYNC, not an add — anyone left out is removed, and an empty list empties the group. Every ID must already belong to the group's team, or the whole call is refused rather than partly applied.
  • update_group — Update Group — PATCH /v1/groups/{group} · group:update Rename a group and replace its permissions. Permissions REPLACE the existing set rather than adding to it — leave the field empty to keep the current one. The code cannot be changed, and membership is untouched here.
  • archive_link — Archive Smart Link — DELETE /v1/projects/{project}/links/{smartLink} · project-link:delete Put a Smart Link out of use. It stops counting clicks and crediting members; its address keeps landing on the portal home, so a flyer or a bio that carries it never shows anyone an error, and the members, purchases and revenue it brought keep their figures. Cannot be undone — make a new link instead.
  • create_link — Create Smart Link — POST /v1/projects/{project}/links · project-link:create Create a Smart Link on a project: a tracked address for one channel (a video description, a bio, a flyer's QR). Every click is counted and every member who signs in within thirty days of clicking is credited to the link. Answers the three addresses to share: the web address, the bot deep link and the embed page. On every plan.
  • update_link — Update Smart Link — PATCH /v1/projects/{project}/links/{smartLink} · project-link:update Partial-update a Smart Link. Only the fields you fill in change; blank fields keep their value. Renaming the address moves the web address and nothing else — the code, the bot link and the attribution cookie survive every edit.

Members (4)

  • ban_member — Ban Member — POST /v1/projects/{project}/members/{member}/ban · project-user:update Ban a project subscriber. Flips status to Banned and emits the member.banned webhook.
  • kick_member — Kick Member — POST /v1/projects/{project}/members/{member}/kick · project-user:update Kick a project subscriber without banning them. Rolls status to Churned.
  • unban_member — Unban Member — POST /v1/projects/{project}/members/{member}/unban · project-user:update Lift a ban on a project subscriber. Restores the subscriber to active status and emits the member.unbanned webhook.
  • unlink_member_identity — Unlink Member Identity — DELETE /v1/projects/{project}/members/{member}/identities/{link} · project-user:update Disconnect one of a member's platform accounts. Refused when it is their last way to sign in. Emits the member.identity_unlinked webhook.

Pass Windows (3)

  • cancel_pass_window — Cancel Pass Window — POST /v1/projects/{project}/pass-windows/{window}/cancel · pass-window:delete Cancel a dated access window and resettle everyone holding it: each holder is moved to the plan's next window on sale, has the date dropped from their season ticket, or has their pass ended and flagged for a refund when nothing is left. Holders are messaged and money may be owed, so confirm the window first. The tallies come back under meta: rebound, refund_due and legs_dropped. Subscriby never moves the refunds itself. An already-cancelled window answers with zero tallies.
  • create_pass_window — Create Pass Window — POST /v1/projects/{project}/plans/{plan}/pass-windows · pass-window:create Place one dated access window by hand on a time-limited pass plan. It is marked manual, so a schedule rebuild keeps it. The start must be in the future and the plan's configured minimum and maximum length apply.
  • remind_pass_window_queue — Remind Pass Window Queue — POST /v1/projects/{project}/pass-windows/{window}/remind · pass-window:update Nudge everyone who bought a window but has not sent their Telegram join request yet, re-attaching their invite links. Answers with how many holders Telegram accepted the message for; a window that has ended or been cancelled reminds nobody. This messages real people — do not repeat it within the same window.

Payment Methods (4)

  • activate_payment_method — Activate Payment Method — POST /v1/projects/{project}/payment-methods/{method}/activate · project-payment-method:update Offer a configured payment gateway at checkout again and re-queue the plan sync for it. A Stripe method whose Connect onboarding never finished is refused — onboarding can only be completed from the dashboard. Activating a method that is already on changes nothing.
  • deactivate_payment_method — Deactivate Payment Method — POST /v1/projects/{project}/payment-methods/{method}/deactivate · project-payment-method:update Stop offering a payment gateway to new buyers; subscriptions already sold through it keep renewing. The plan sync for the gateway is re-queued. Deactivating a method that is already off changes nothing.
  • delete_payment_method — Delete Payment Method — DELETE /v1/projects/{project}/payment-methods/{method} · project-payment-method:delete Remove a payment gateway from a project. Buyers lose that way to pay at once; subscriptions already sold through it keep their gateway for refunds and history, and configuring the same gateway again later revives the row.
  • sync_payment_method_plans — Sync Payment Method Plans — POST /v1/projects/{project}/payment-methods/{method}/sync · project-payment-method:update Queue a push of the project's plans into a gateway's catalogue (Stripe products and prices, PayPal, Razorpay or CoinPayments plans). Answers sync_queued at once; the work runs in the background and each plan reports through the plan.sync_completed event. A gateway that keeps no catalogue (Telegram Stars, access codes, the redirect gateways) is refused.

Plans (6)

  • create_plan — Create Plan — POST /v1/projects/{project}/plans · project-subscription-plan:create Create a plan on a Subscriby project. Pick a kind first — a recurring subscription, a time-limited pass that sells one dated window, or a pass series that sells a whole slate of your pass plans' windows for one payment. The fields below change to match.
  • delete_plan — Delete Plan — DELETE /v1/projects/{project}/plans/{plan} · project-subscription-plan:delete Permanently delete a plan within a project. Active subscriptions must be migrated or cancelled beforehand — the API rejects deletes otherwise.
  • publish_plan — Publish Plan — POST /v1/projects/{project}/plans/{plan}/publish · project-subscription-plan:update Activate a plan so new sign-ups can purchase it. Emits plan.activated. Noop if already active.
  • start_next_season — Start Next Season — POST /v1/projects/{project}/plans/{plan}/successor · project-subscription-plan:create Create the successor of a pass series plan: a new season built from the same series, carrying its rules onto the next run of windows, so a season ticket can be sold again without re-authoring it. The current season is untouched. Only a plan of kind pass_series has a successor; any other kind is refused.
  • unpublish_plan — Unpublish Plan — POST /v1/projects/{project}/plans/{plan}/unpublish · project-subscription-plan:update Deactivate a plan so new sign-ups can no longer purchase. Existing subscribers keep their subscription; only new sign-ups are blocked. Emits plan.deactivated.
  • update_plan — Update Plan — PATCH /v1/projects/{project}/plans/{plan} · project-subscription-plan:update Partial-update an existing plan. Pick the kind the plan already is — the fields below change to match, and sending a block belonging to another kind is refused. Lifetime count=1, mutually-exclusive eligibility flags, recurring-vs-crypto and currency support checks all run server-side.

Projects (12)

  • archive_project — Archive Project — POST /v1/projects/{project}/archive · project:update Flip a project to active=false. Emits project.archived. Noop if already archived.
  • create_project — Create Project — POST /v1/projects · project:create Create a new Subscriby project. Delegates to the REST v1 endpoint — plan limits, the custom_handle tier gate, and cache invalidation all run server-side.
  • delete_project — Delete Project — DELETE /v1/projects/{project} · project:delete Permanently delete a Subscriby project. Subscribers, plans, resources, and access codes are removed server-side.
  • disconnect_connector — Disconnect Connector — DELETE /v1/projects/{project}/connectors/{key}/installation · project-connector:delete Disconnect a project's installation of one connector: the connector withdraws it, the credentials are wiped and the installation turns disconnected. Members keep their access; grants, resources, plans and identities are untouched; the creator can connect it again from the dashboard. The neutral twin of Disconnect Bot.
  • install_connector — Install Connector — POST /v1/projects/{project}/connectors/{key} · project-connector:create Install a connector on a project: opens a pending installation with no credentials yet, which the creator connects from the dashboard. Installing one that is already installed changes nothing. Refused for a connector that is not installable today, or for a second connector when the project owner's plan lacks the multi-connector capability.
  • restore_connector_access — Restore Connector Access — POST /v1/projects/{project}/connectors/{key}/installation/restore-access · project-connector:update Bring a project's detached places on a reinstalled connector back. Every resource the uninstall detached is asked about; the ones the connector still controls are reactivated, and every live purchase of a plan granting them is handed fresh access (Member Resource Added fires per grant issued). Places the connector no longer controls stay detached for Run Connector Doctor to explain; plans taken off sale stay off sale. Refused until the installation is connected again.
  • restore_project — Restore Project — POST /v1/projects/{project}/restore · project:update Flip a previously archived project back to active. Emits project.restored. Noop if already active.
  • run_connector_doctor — Run Connector Doctor — POST /v1/projects/{project}/connectors/{key}/installation/doctor · project-connector:update Verify a project's installation of a connector and ask the connector about every resource it gates. Answers one report with a finding per check: the installation first, then each resource, each with its severity (ok, warning, critical), the connector's own state word and sentence, whether the creator can fix it and where. The report is kept on the installation; Connector Doctor Completed fires only when the findings changed.
  • uninstall_connector — Uninstall Connector — DELETE /v1/projects/{project}/connectors/{key} · project-connector:delete Uninstall a connector from a project: every live grant on its resources is revoked, its resources are deactivated as detached, the installation row is kept and identities are never removed. Two opt-ins, on by default, act on the plans left with nothing to grant: take them off sale, and cancel their recurring subscriptions at period end with an email to each member. Run Get Connector Uninstall Preview first.
  • update_connector_installation_settings — Update Connector Installation Settings — PATCH /v1/projects/{project}/connectors/{key}/installation/settings · project-connector:update Change a project's connector installation settings. Keys are the field names the connector declares (read them with Get Connector); every declared rule runs, an undeclared key is refused, and fields left out keep their value. Values are never returned.
  • update_project — Update Project — PATCH /v1/projects/{project} · project:update Partial-update an existing Subscriby project. Only fields you supply are changed; omitted fields keep their current value. Handle uniqueness and custom_handle tier gate are enforced server-side.
  • verify_connector_installation — Verify Connector Installation — POST /v1/projects/{project}/connectors/{key}/installation/verify · project-connector:update Ask the connector whether a project's installation still answers and record the verdict on it: connected, degraded (with the reason) or revoked. A pending installation is returned as it is. Fires Connector Status Changed only when the state moved.

Recovery (12)

  • notify_members_of_recovery — Notify Members Of Recovery — POST /v1/recovery/operations/{operation}/notify-members · project-recovery:update Email every member the project can reach that its bot changed after a bot replacement, at the per-email fee. Sent once per recovery.
  • nudge_pending_readmissions — Nudge Pending Readmissions — POST /v1/recovery/operations/{operation}/nudge · project-recovery:update Send one reminder, with a fresh link, to every member a channel recovery re-admitted who has not joined the new chat yet.
  • remove_resource_standby — Remove Resource Standby — DELETE /v1/projects/{project}/resources/{resource}/standby · project-recovery:delete Stop keeping a standby for one resource; the chat itself is untouched and the resource keeps its live chat.
  • remove_standby_installation — Remove Standby Installation — DELETE /v1/projects/{project}/recovery/standby-installation · project-recovery:delete Stop keeping the standby installation (the spare bot) registered for a project.
  • request_resource_replacement — Request Resource Replacement — POST /v1/projects/{project}/resources/{resource}/replacement/request · project-recovery:create Ask the creator, through the connector, to pick the chat that replaces a resource's; the swap runs the moment they choose. Nothing is swapped by the call itself.
  • request_resource_standby — Request Resource Standby — POST /v1/projects/{project}/resources/{resource}/standby/request · project-recovery:create Ask the creator, through the connector, to pick the chat that becomes the standby for one resource. Nothing is linked by the call itself.
  • revert_recovery_operation — Revert Recovery Operation — POST /v1/recovery/operations/{operation}/revert · project-recovery:update Undo a completed Disaster Recovery inside its window — a swapped channel put back, or the previous sign-in account restored.
  • set_resource_standby_mirror — Set Resource Standby Mirror — PATCH /v1/projects/{project}/resources/{resource}/standby · project-recovery:update Switch the live mirror into a resource's standby on or off, so a failover lands members in a channel that already holds the content.
  • update_recovery_settings — Update Recovery Settings — PATCH /v1/projects/{project}/recovery/settings · project-recovery:update Change one project's Disaster Recovery settings: switch automatic failover on or off (with the fee consent), and choose how members are told after a swap. Fields left out keep their value.
  • use_resource_standby — Use Resource Standby — POST /v1/projects/{project}/resources/{resource}/standby/use · project-recovery:create Swap a resource onto its standby right now: old links revoked, every active member re-admitted, the standby consumed. Returns the recovery operation it ran under.
  • withdraw_resource_replacement_request — Withdraw Resource Replacement Request — DELETE /v1/projects/{project}/resources/{resource}/replacement/request · project-recovery:delete Take back the replacement request the creator has open on the connector. Takes no input.
  • withdraw_resource_standby_request — Withdraw Resource Standby Request — DELETE /v1/projects/{project}/resources/{resource}/standby/request · project-recovery:delete Take back the standby request the creator has open on the connector. Takes no input.

Referral Affiliates (3)

  • add_referral_affiliate — Add Referral Affiliate — POST /v1/projects/{project}/referral-affiliates · project-referral:create Enrol a member of a project as an affiliate of its Referral Program by hand: approved whatever the programme's customers-only and approval switches say, and handed their code, their links and the programme's terms in their chat and by mail. Refused when the member already stands in the programme. Raises New Referral Affiliate.
  • approve_referral_affiliate — Approve Referral Affiliate — POST /v1/projects/{project}/referral-affiliates/{affiliate}/approve · project-referral:update Approve a pending or suspended affiliate: their code counts from now on, and they receive their link, code and the programme's terms in their chat and by mail. Raises Referral Affiliate Approved. An affiliate already approved is left as they are.
  • suspend_referral_affiliate — Suspend Referral Affiliate — POST /v1/projects/{project}/referral-affiliates/{affiliate}/suspend · project-referral:update Suspend an affiliate: their code stops counting new friends and nothing new is earned, while what they already earned stays and can still be paid out. Raises Referral Affiliate Suspended. An affiliate already suspended is left as they are.

Referral Payouts (1)

  • record_referral_payout — Record Referral Payout — POST /v1/projects/{project}/referral-payouts · project-referral:update Record a payout you made to an affiliate outside Subscriby, so the ledger marks their oldest payable commissions in that currency as paid, first in first out, until the amount is covered. The amount is capped at the affiliate's payable balance in that currency; read it with Get Referral Affiliate first. Raises Referral Payout Recorded.

Referral Program (4)

  • activate_referral_program — Activate Referral Program — POST /v1/projects/{project}/referral-program/activate · project-referral:update Switch a project's Referral Program on: affiliates' links and codes attribute again, settled payments earn again, and every affiliate is told the terms as they now stand. Raises Referral Program Updated with "active" as the one change. A programme already on is left as it is.
  • deactivate_referral_program — Deactivate Referral Program — POST /v1/projects/{project}/referral-program/deactivate · project-referral:update Switch a project's Referral Program off: links and codes stop attributing and payments stop earning at once, while what affiliates already earned stays and can still be paid out. Every affiliate is told their link no longer counts new friends. Raises Referral Program Updated. A programme already off is left as it is.
  • delete_referral_program — Delete Referral Program — DELETE /v1/projects/{project}/referral-program · project-referral:delete Remove a project's Referral Program. Refused while any affiliate is still owed a commission: record their payouts first, or use Deactivate Referral Program, which stops the programme and keeps everything. Deleting raises no event.
  • update_referral_program — Update Referral Program — PUT /v1/projects/{project}/referral-program · project-referral:update Set up or change a project's Referral Program. The first call on a project creates it; every later call changes only the fields you fill in, blank fields keep their value. Rewards already in the ledger keep their figures, and every approved or pending affiliate is told the new terms in their chat and by mail. Needs the Referral Program Addon or a Growth plan.

Resources (7)

  • activate_resource — Activate Resource — POST /v1/projects/{project}/resources/{resource}/activate · project-resource:update Switch a resource back on so plans grant it to members again. Activating a resource that is already on changes nothing.
  • create_resource — Create Resource — POST /v1/projects/{project}/resources · project-resource:create Create a manual perk (custom text content, an external URL, a token the creator hands over by hand). A place a connector gates is linked through the connector with Request Resource Link; only manual perks are created here, and only once a connector on the project is connected.
  • deactivate_resource — Deactivate Resource — POST /v1/projects/{project}/resources/{resource}/deactivate · project-resource:update Switch a resource off without deleting it. It keeps its Telegram link but drops out of what plans grant until switched back on. Deactivating a resource that is already off changes nothing.
  • delete_resource — Delete Resource — DELETE /v1/projects/{project}/resources/{resource} · project-resource:delete Delete a project resource row. The linked Telegram destination is unlinked first if applicable.
  • request_resource_link — Request Resource Link — POST /v1/projects/{project}/resources/link-requests · project-resource:create Ask the creator, through the connector, to pick the place a new resource will be (a kind of place the connector gates, such as a Telegram channel); the resource appears the moment they choose. Nothing is created by the call itself. Manual perks are created with Create Resource instead.
  • unlink_resource — Unlink Resource — POST /v1/projects/{project}/resources/{resource}/unlink · project-resource:update Detach the place from a project resource. The row remains and keeps its kind and connector; it is bound to no space until the creator links another through the connector.
  • update_resource — Update Resource — PATCH /v1/projects/{project}/resources/{resource} · project-resource:update Change a resource's title, description or on/off switch. Partial: only the fields you fill in change, so a title-only update leaves the description as stored. The type and Telegram link are not editable here.

Retention (1)

  • update_retention_settings — Update Retention Settings — PUT /v1/projects/{project}/retention · project-subscription:update Change a project's Revenue Recovery settings: the grace window a failed renewal keeps access for, the daily digest, the cancellation question, the three offers the cancellation screen can make, the checkout window after which a checkout counts as stalled and the trial reminder before a cardless trial ends. Only the fields you fill in change; blank fields keep their value.

Roles (3)

  • create_role — Create Role — POST /v1/roles · role:create Create a permission role inside a team. The code is the stable identifier permissions are addressed by — it must be unique within the team and cannot be changed later. Growth-tier feature.
  • delete_role — Delete Role — DELETE /v1/roles/{role} · role:delete Delete a team role and detach its permissions. Anyone holding the role loses whatever it granted. Restricted to whoever created the role, unless you own the team.
  • update_role — Update Role — PATCH /v1/roles/{role} · role:update Rename a role and replace its permissions. Permissions REPLACE the existing set rather than adding to it — send the full list you want the role to end up with, or leave the field empty to keep the current one. The code cannot be changed.

Sequences (3)

  • create_sequence — Create Sequence — POST /v1/projects/{project}/sequences · project-sequence:create Build a sequence on a project: the ordered messages a member receives on the days you choose after one of four moments (they left, they arrived as a lead, their checkout stalled, their trial is about to end), each with the way to the plan as a button. The steps are written with the sequence in one call. Needs Growth or the Revenue Recovery Addon on the project owner.
  • delete_sequence — Delete Sequence — DELETE /v1/projects/{project}/sequences/{sequence} · project-sequence:delete Put a recovery sequence out of use: every member part-way through leaves it at once, the row and its history stay for the figures, and the id stops answering. Never undone; to stop a sequence without losing it, set it inactive with Update Sequence instead.
  • update_sequence — Update Sequence — PATCH /v1/projects/{project}/sequences/{sequence} · project-sequence:update Change a sequence. Only the fields you fill in change; blank fields keep their value. Steps, when given, replace the whole list in order: a step still at its place keeps its id, the rest are added and the extra ones removed from the end. Switching the sequence off lets every member part-way through go.

Subscriptions (6)

  • cancel_subscription — Cancel Subscription — POST /v1/subscriptions/{subscription}/cancel · project-subscription:update Queues cancellation for a Subscriby subscription. Provider-side cancellation + local state mutation run asynchronously; the action returns once the job is queued.
  • pause_subscription — Pause Subscription Access — POST /v1/subscriptions/{subscription}/pause · project-subscription:update Suspend a member’s access to the project’s linked Telegram resources. Billing is NOT affected — the payment provider keeps charging on schedule. Use Unpause Subscription Access to restore it with fresh invite links.
  • reactivate_subscription — Reactivate Subscription — POST /v1/subscriptions/{subscription}/reactivate · project-subscription:update Call off a scheduled cancellation so the subscription keeps billing normally — the win-back action. Stripe only: on every other provider cancelling ends the agreement outright and the member must subscribe again.
  • reissue_subscription_grants — Reissue Subscription Grants — POST /v1/subscriptions/{subscription}/grants/reissue · project-subscription:update Revoke the access grants a member holds on a subscription — every resource, or one — and have fresh ones issued. The invite links they held die and the bot sends them the new ones. Raises Member Access Reissued per resource, then Member Added to Resource for each fresh grant.
  • remind_pass_holder — Remind Pass Holder — POST /v1/subscriptions/{subscription}/remind · project-subscription:update Nudge one pass holder who bought a window but has not sent their Telegram join request yet, re-attaching their invite links. Answers reminded: true when Telegram accepted the message and reminded: false when there was nothing to send — no window on the subscription, a window that has ended or been cancelled, a holder who already queued, or one who cannot be reached. False is a normal answer, not an error. Do not repeat the nudge within the same window.
  • unpause_subscription — Unpause Subscription Access — POST /v1/subscriptions/{subscription}/unpause · project-subscription:update Restore a suspended member’s access, issuing fresh invite links. Only works on a subscription that is currently paused.

Support Canned Replies (3)

  • create_canned_reply — Create Canned Reply — POST /v1/projects/{project}/support/canned-replies · support-canned-reply:create Save a reply snippet to a project's support picker, so agents can insert it with one click or by typing its shortcut. The shortcut must be unique within the project.
  • delete_canned_reply — Delete Canned Reply — DELETE /v1/projects/{project}/support/canned-replies/{reply} · support-canned-reply:delete Remove a saved reply from a project's support picker. Replies already sent with the snippet are untouched.
  • update_canned_reply — Update Canned Reply — PATCH /v1/projects/{project}/support/canned-replies/{reply} · support-canned-reply:update Change a saved support reply. Partial: only the fields you fill in change, and a call that restates the stored values writes nothing.

Support Conversations (6)

  • assign_support_conversation — Assign Support Conversation — POST /v1/support/conversations/{conversation}/assign · support-conversation:update Hand a support conversation to a team member. Leave Assignee empty to clear an existing assignment.
  • block_support_contact — Block Support Contact — POST /v1/support/conversations/{conversation}/block · support-conversation:update Block the member behind a support conversation: their messages to the project's bot are dropped without notice and the thread cannot reopen on inbound. Their paid access is untouched — use Ban Member for moderation. Blocking an already-blocked contact changes nothing.
  • reopen_support_conversation — Reopen Support Conversation — POST /v1/support/conversations/{conversation}/reopen · support-conversation:update Put a resolved support conversation back in the open queue. A member writing back reopens a thread on its own; use this when a creator changes their mind or owes a follow-up before the member speaks again.
  • reply_support_conversation — Reply to Support Conversation — POST /v1/support/conversations/{conversation}/messages · support-conversation:update Send a reply to a member in a support conversation. The member receives it on Telegram as a bot message attributed to you, so treat this as sending a real message to a real person. Set Internal Note to record a private remark for your team instead.
  • resolve_support_conversation — Resolve Support Conversation — POST /v1/support/conversations/{conversation}/resolve · support-conversation:update Mark a support conversation resolved, clearing it from the open queue. Nothing is deleted, and the conversation reopens by itself if the member writes again.
  • unblock_support_contact — Unblock Support Contact — POST /v1/support/conversations/{conversation}/unblock · support-conversation:update Lift a support block so the member behind the conversation can reach the inbox again. Unblocking a contact who is not blocked changes nothing.

Support Settings (1)

  • update_support_settings — Update Support Settings — PATCH /v1/projects/{project}/support/settings · project:update Change a project's support inbox settings. Partial: only the fields you fill in change. Turning support off stops new member threads reaching the inbox; existing threads are kept.

Team Members (4)

  • cancel_team_invitation — Cancel Team Invitation — DELETE /v1/teams/{team}/invitations/{invitation} · team-member:remove Withdraw an invitation nobody has accepted yet, so its link stops working. Distinct from Remove Team Member: an invitee has no membership row, only a pending invitation, and the two fail on different things.
  • update_team_member_role — Change Team Member Role — PATCH /v1/teams/{team}/members/{member}/role · team-member:update-role Move an existing collaborator onto a different role. The team owner cannot be re-roled — ownership is not a membership row — and someone who is not in the team is refused. Fires the Team Member Role Changed trigger.
  • invite_team_member — Invite Team Member — POST /v1/teams/{team}/members · team-member:invite Invite someone to a team by email and send them an invitation. Addressed by email rather than user ID because the invitee may not have an account yet. The role must already exist on the team — create it first with Create Role. Someone already in the team is refused.
  • remove_team_member — Remove Team Member — DELETE /v1/teams/{team}/members/{member} · team-member:remove Remove a collaborator from a team. They immediately lose access to every project and setting scoped to it, though their own account is untouched. The team owner cannot be removed. To withdraw an invitation nobody has accepted, use Cancel Team Invitation instead.

Teams (3)

  • create_team — Create Team — POST /v1/teams · team:create Create a Subscriby team. Teams are the tenant every project, plan and subscription belongs to, and are a Growth-tier feature — a lower tier returns TEAM_TIER_REQUIRED. The token owner becomes the team owner.
  • delete_team — Delete Team — DELETE /v1/teams/{team} · team:delete Permanently delete a Subscriby team, owner only. Every project, plan and subscription scoped to the team goes with it and there is no restore. Your last remaining team is refused — an account with no tenant is not a valid state.
  • update_team — Update Team — PATCH /v1/teams/{team} · team:update Rename a Subscriby team. Owner only — belonging to a team is not enough. Name is the only mutable field; membership and roles move through their own actions.

Tokens (1)

  • revoke_token — Revoke Token — DELETE /v1/tokens/{token} · token:delete Revoke a personal access token. Subsequent requests using that token will fail with 401.

Webhook Deliveries (2)

  • retry_dead_webhook_deliveries — Retry Dead Webhook Deliveries — POST /v1/webhook-deliveries/retry-dead · webhook-delivery:retry Replay every webhook delivery the team dead-lettered since a point in time, once the consumer is fixed. Leave Since blank for the last 24 hours, the same window the dashboard's Replay button uses. Each replayed row posts its event again, so confirm the consumer is healthy first.
  • retry_webhook_delivery — Retry Webhook Delivery — POST /v1/webhook-deliveries/{delivery}/retry · webhook-delivery:retry Replay one failed or dead-lettered webhook delivery from the start of the retry ladder, posting the same event to the same endpoint again. A pending or already-delivered row is refused, because replaying it would post the event twice.

Webhook Endpoints (6)

  • create_webhook_endpoint — Create Webhook Endpoint — POST /v1/webhook-endpoints · webhook-endpoint:create Register a new webhook endpoint. The one-time plaintext signing secret is returned on creation and is exposed as the "secret" output field — store it now, it will not be shown again.
  • delete_webhook_endpoint — Delete Webhook Endpoint — DELETE /v1/webhook-endpoints/{endpoint} · webhook-endpoint:delete Remove a webhook endpoint. Pending deliveries will be dropped server-side.
  • pause_webhook_endpoint — Pause Webhook Endpoint — POST /v1/webhook-endpoints/{endpoint}/pause · webhook-endpoint:update Stop deliveries to a webhook endpoint without deleting it. Events raised while it is paused are not queued for it and are not replayed on resume. Only the member who registered the endpoint, or the team owner, may pause it.
  • resume_webhook_endpoint — Resume Webhook Endpoint — POST /v1/webhook-endpoints/{endpoint}/resume · webhook-endpoint:update Restart deliveries to a paused webhook endpoint and clear its consecutive-failure streak, so a target that was fixed is not disabled again on its first miss. Events raised while it was paused are not replayed; use Retry Dead Webhook Deliveries for rows that dead-lettered before the pause.
  • rotate_webhook_secret — Rotate Webhook Secret — POST /v1/webhook-endpoints/{endpoint}/rotate-secret · webhook-endpoint:update Regenerate the signing secret for a webhook endpoint. The new plaintext secret is returned once — store it immediately.
  • test_webhook_endpoint — Test Webhook Endpoint — POST /v1/webhook-endpoints/{endpoint}/test · webhook-endpoint:update Send a synthetic test event to a webhook endpoint. Useful for verifying the receiver signature + 2xx handling before relying on production deliveries.

Notes on specific actions

Plan

Plan Kind — a breaking change in 3.0.0

Create Plan and Update Plan now open with a Plan Kind dropdown, and the fields below it change to match:

Plan KindSells
Recurring SubscriptionAccess that begins at payment and renews on a cycle.
Time-Limited PassOne dated access window per purchase.
Pass SeriesA slate of other pass plans' windows, sold once — a season ticket.

Only the fields your chosen kind accepts are shown, mirroring the API, which refuses a block belonging to another kind rather than ignoring it.

Existing Zaps need their fields re-mapped

The field keys behind these two actions changed in 3.0.0. A Zap that set Billing Cycle still sets one — the field moved into the subscription kind's group — but the mapping has to be re-made by whoever built the Zap. No other trigger, action or search changed its keys.

Building a Pass Series

A series points at windows that already exist on your pass plans, so the order matters:

  1. Find Pass Windows — the new search. Returns each window's ID, its local range, whether it is still on sale and how many people hold it. Filter by plan, status or date range.
  2. Create Plan with Plan Kind → Pass Series, pasting those IDs into Pass Window IDs.
  3. Optionally add Automatic Inclusion Rules. A rule describes windows rather than naming them and keeps matching after the save: a window scheduled later is added to the slate and granted to everyone already holding the series, at no charge. Handpicked IDs never grow on their own — the two compose.

Resource IDs is optional on a series and means a lounge the holder keeps for the whole span; each window already grants its own plan's resources.

Recovery

All run the same actions the Disaster Recovery pages run, so a refusal (a teammate, a plan without the feature, a closed undo window) comes back as the dashboard's own sentence.

Broadcast

Sends one Telegram message to a segment of a project's members. The send is queued, so the action returns the audience it resolved and the recipient count — not a delivery result. Pair it with the Broadcast Completed trigger to log sent and failed.

Test action sends for real

A broadcast cannot be recalled, and Audience defaults to All Users. Clicking Test action while building the Zap sends a real message to every member with a linked chat, not a sample. Set the audience — and, if you want it, the plan — before you test, or point the test at a project with no members.

Choosing the audience

Three fields compose. Audience picks a segment, Narrow to a Plan optionally restricts it to one plan, and Running Out Within (Days) sets the horizon that Expiring Soon reads.

GroupSegments
Member statusAll Users, Customers Only, Trialing Users, Leads, Churned Users
Subscription stateExpiring Soon, Cancelled Still Inside Their Period, Paused Subscriptions, Trialing Without a Card
PassesAll Active Pass Holders, All Active Pass Holders Not in Queue, and the two single-window forms

Narrow to a Plan composes rather than replaces: Customers Only plus a plan reaches people paying for it right now, Churned Users plus a plan reaches people who held it and left. The plan and the state always describe the same subscription, so somebody paying for Silver who once trialled Gold is not a Gold customer.

The API refuses a plan on Leads, who never subscribed, and on the pass segments, whose plan is implied by the window — a 422 rather than a silently widened send.

An auto-renewing subscription is never Expiring Soon

A subscription's end date is rewritten to the new period end every time it renews, so a date inside the horizon describes the next invoice, not an expiry. Counting it would sweep every monthly subscriber into the segment once a month. A member appears only once their access genuinely lapses — renewal is off, or the plan does not renew at all.

The two single-window pass segments additionally require a Pass Window ID; the API refuses the send without one rather than quietly addressing nobody.

Team + RBAC

Two of these replace rather than merge

Permissions replace. Sending the permissions field on Update Role or Update Group makes that list the entire set. Omit it to leave existing permissions alone.

Sync Group Members is a sync, not an add. Anyone missing from the list is removed from the group, and an empty list empties it. Read the group first if you mean to append.

Creating and re-permissioning need the Growth plan. Deleting and removing do not — a creator whose plan lapsed still has collaborators attached and has to be able to take access away.

Searches

Return a single object (wrapped in [x]) or an array. Use them in dynamic dropdowns, cross-Zap lookups, or as standalone fetch steps.

93 searches, grouped by what they read. Each line names the Zapier key, the label you pick in the editor, the route it calls and the token ability that route needs.

Access Codes (2)

  • list_access_codes — List Access Codes — GET /v1/projects/{project}/plans/{plan}/access-codes · project-access-code:view-any List access codes for a plan, optionally filtered by status.
  • preview_access_code_cost — Preview Access Code Cost — GET /v1/projects/{project}/plans/{plan}/access-codes/preview · project-access-code:view-any Preview the cost (in platform credits / currency) of generating a batch of access codes for a plan.

Account (7)

  • find_partner_payouts — Find Partner Payouts — GET /v1/me/partner/payouts · account:read List the cash payouts Subscriby made to you as a partner, newest first: the amount, the rail it went by, the transfer's reference, when it left and how many commissions it covered. Commissions settled as Subscriby Credit are not payouts; find them with Find Partner Rewards as "credited".
  • find_partner_referrals — Find Partner Referrals — GET /v1/me/partner/referrals · account:read List the creators you brought to Subscriby as a partner, newest first: each named by display name alone, how they arrived, whether their first paid invoice converted them, the plan they converted on, the rate locked onto them and until when you earn on them. Narrow by status.
  • find_partner_rewards — Find Partner Rewards — GET /v1/me/partner/rewards · account:read List your Partner Program commission ledger, newest first: one "commission" row per paid invoice of a creator you referred, priced from the invoice's total before tax and after discount at the referral's locked rate, plus the "clawback" rows that answer a reversal of money already settled. Narrow by status: pending (inside the hold), approved (payable), credited (applied as Subscriby Credit), paid (covered by a cash payout) or reversed.
  • get_me — Get Me — GET /v1/me · account:read Retrieve the creator the token belongs to: the team it is scoped to, every team held, plan capabilities, connected accounts and alert destinations.
  • get_partner_program — Get Partner Program — GET /v1/me/partner · account:read Retrieve where the token's creator stands in the Partner Program, Subscriby's own programme that pays a share of every invoice the creators you bring to Subscriby pay: the application's state, your code and links once approved, the commission ladder, the referral tallies, the balances, the payout rail and whether it is complete (never the destination itself), the tax declaration, the terms and your commitments. Returns no rows until you apply, which is done on the dashboard or in the bot.
  • get_partner_referral — Get Partner Referral — GET /v1/me/partner/referrals/{referral} · account:read Retrieve one creator you referred by the referral's UUID: how they arrived, whether their first paid invoice converted them and on which plan, the rate locked onto them and until when you earn on them. Returns no rows for another partner's referral.
  • list_notifications — List Notifications — GET /v1/me/notifications · account:read List the entries of your notification centre, newest first — every alert Subscriby sent you, with its class, title, body, where it points and whether it was read — or only the unread ones, or one class.

Activity (1)

  • list_activity — List Activity — GET /v1/activity · activity:read List activity log entries for a given subject (project, subscription, member, plan, access-code).

Analytics (8)

  • get_connector_analytics — Get Connector Analytics — GET /v1/analytics/connectors · dashboard:read Retrieve members, access and revenue per connector for the team or a specific project: live installations, members with a linked account, live and pending grants, grants issued and revoked in the window, gross revenue in USD and its share. A purchase spanning two connectors counts toward both.
  • get_dashboard_metrics — Get Dashboard Metrics — GET /v1/analytics/dashboard · dashboard:read Retrieve the dashboard metric cards for the current team or a specific project.
  • get_earnings_report — Get Earnings Report — GET /v1/analytics/earnings · dashboard:read Retrieve the earnings (net revenue) time series for the current team or a specific project.
  • get_plan_performance — Get Plan Performance — GET /v1/analytics/plan-performance · dashboard:read Retrieve per-plan performance metrics (subscribers, revenue, conversion) for a project.
  • get_revenue_composition — Get Revenue Composition — GET /v1/analytics/composition · dashboard:read Retrieve how revenue and payments are composed for the team or a specific project: transaction fees by payment provider, settled transactions by plan kind, gross revenue by currency, payment attempts by outcome, and the monthly recurring revenue split by plan. Each dataset carries its total, unit and slices with shares.
  • get_subscriber_analytics — Get Subscriber Analytics — GET /v1/analytics/subscribers · dashboard:read Retrieve subscriber growth, churn, and cohort analytics for the team or a specific project.
  • get_transaction_breakdown — Get Transaction Breakdown — GET /v1/analytics/transactions/breakdown · dashboard:read Retrieve a transaction breakdown grouped by plan, payment provider, currency, or project.
  • list_transactions — List Transactions — GET /v1/analytics/transactions · dashboard:read List transactions for a project, filterable by status, provider, plan, or currency. Returns a cursor-paginated page.

Connectors (2)

  • get_connector — Get Connector — GET /v1/connectors/{key} · project-connector:view-any Retrieve one Connectors Marketplace card by key — its lane, badges and, for a connector that exists as a package, its manifest and the form that connects it.
  • list_connectors — List Connectors — GET /v1/connectors · project-connector:view-any List the Connectors Marketplace — every connector Subscriby knows, lane by lane, with its badges, manifest and the declarative form that connects it.

Coupons (2)

  • find_coupons — Find Coupons — GET /v1/projects/{project}/coupons · project-coupon:view-any List a project’s coupons, newest first, optionally narrowed to one exact code or to the on/off switch. Read "redeemable" on each row for whether a code actually applies right now — "active" is only the switch.
  • get_coupon — Get Coupon — GET /v1/projects/{project}/coupons/{coupon} · project-coupon:view Retrieve one coupon by UUID, with its discount, limits, live redemption tally and sales window. "redemptions.remaining" already accounts for checkouts in flight, so prefer it over subtracting the count from the cap yourself.

Creator Tasks (1)

  • list_creator_tasks — List Creator Tasks — GET /v1/projects/{project}/creator-tasks · project-subscription:view List the hand-arranged perks a creator still has to hand over in a project — one task per subscriber and manual resource, oldest first — or the ones already done.

Distribution (2)

  • get_deep_link — Get Deep Link — GET /v1/projects/{project}/distribution/deep-link · distribution:read Generate a deep link for a project. Pass at most one of access_code, plan_id, or custom — omit all to get the default project link.
  • get_portal_url — Get Portal URL — GET /v1/projects/{project}/distribution/portal-url · distribution:read Retrieve the public subscriber portal URL for a project.

Groups (2)

  • get_group — Get Group — GET /v1/groups/{group} · group:view Retrieve a single collaborator group by UUID.
  • list_groups — List Groups — GET /v1/groups · group:view-any List every collaborator group defined on the current team.
  • find_links — Find Smart Links — GET /v1/projects/{project}/links · project-link:view-any List a project's Smart Links, newest first, each with its three addresses and lifetime clicks; narrow to archived links or to links still in use, or search by name or address. Read "state" on each row: live, expired or archived.
  • get_link — Get Smart Link — GET /v1/projects/{project}/links/{smartLink} · project-link:view Retrieve one Smart Link by UUID: its name, address, stable code, destination, the three addresses to share (web, bot, embed page), its state and its lifetime clicks. Get Smart Link Funnel has the members and the revenue behind it.
  • get_link_funnel — Get Smart Link Funnel — GET /v1/projects/{project}/links/funnel · project-link:view-any, GET /v1/projects/{project}/links/{smartLink}/funnel · project-link:view Read the funnel behind Smart Links: lifetime clicks, the members a link brought, those who started a purchase, those who paid, the conversion rate and everything those members ever paid, per currency and in US dollars. With a Smart Link ID, one link's row; without, every link of the project plus the Direct row and totals that add up to the project's own figures.

Members (4)

  • find_member_by_identity — Find Member by Connector Account — GET /v1/projects/{project}/members · project-user:view-any Look up a project member by the account they connected on a connector: the connector and the platform's own id for the account, as a bot or a server hands it over.
  • find_member_by_id — Find Member by ID — GET /v1/projects/{project}/members/{member} · project-user:view Look up a project member by their UUID. Pair with Member Joined / Member Banned triggers for follow-up steps.
  • list_member_identities — List Member Identities — GET /v1/projects/{project}/members/{member}/identities · project-user:view List the platform accounts a project member has connected, with the one the project reaches first marked preferred.
  • list_members — List Members — GET /v1/projects/{project}/members · project-user:view-any List members within a project, optionally filtered by status.

Pass Windows (2)

  • find_pass_windows — Find Pass Windows — GET /v1/projects/{project}/pass-windows · pass-window:view-any List the dated access windows a project's time-limited pass plans generate, with their IDs. This is where the Pass Window IDs for a Pass Series come from — a series points at windows that already exist rather than creating any, so run this first, then feed the IDs into Create Plan.
  • get_pass_window — Get Pass Window — GET /v1/projects/{project}/pass-windows/{window} · pass-window:view Retrieve one dated access window by UUID, with its local range, lifecycle status, whether it is still on sale and how many holders bought it.

Payment Methods (2)

  • get_payment_method — Get Payment Method — GET /v1/projects/{project}/payment-methods/{method} · project-payment-method:view Retrieve a single project payment method by UUID.
  • list_payment_methods — List Payment Methods — GET /v1/projects/{project}/payment-methods · project-payment-method:view-any List the payment providers enabled for a project.

Plans (3)

  • find_plan_by_id — Find Plan by ID — GET /v1/projects/{project}/plans/{plan} · project-subscription-plan:view Look up a plan by its UUID on a given project. Direct lookup — faster than the name-based search for ID-driven flows.
  • find_plan_by_name — Find Plan by Name — GET /v1/projects/{project}/plans · project-subscription-plan:view-any Look up a plan by its name within a specific project.
  • list_plans — List Plans — GET /v1/projects/{project}/plans · project-subscription-plan:view-any List every plan within a project.

Projects (6)

  • find_project_by_handle — Find Project by Handle — GET /v1/projects · project:view-any Look up a project by its URL handle (e.g. "research-premium").
  • get_connector_installation — Get Connector Installation — GET /v1/projects/{project}/connectors/{key}/installation · project-connector:view Retrieve a project's live installation of one connector — its state, health and the platform's own account for it. The neutral twin of Get Bot Status.
  • get_connector_uninstall_preview — Get Connector Uninstall Preview — GET /v1/projects/{project}/connectors/{key}/uninstall-preview · project-connector:view Show what uninstalling a connector from a project would touch, changing nothing: its resources, the live grants on them, the plans left with nothing to grant, the subscriptions on those plans, and the opt-in defaults.
  • get_project — Get Project — GET /v1/projects/{project} · project:view Retrieve a single project by its UUID.
  • list_connector_installations — List Connector Installations — GET /v1/projects/{project}/connectors · project-connector:view-any List every connector installation a project holds — live and standby — with its state, health and the platform's own account for it.
  • list_projects — List Projects — GET /v1/projects · project:view-any List every project the authenticated token can access.

Recovery (7)

  • get_recovery_allowances — Get Recovery Allowances — GET /v1/recovery/allowances · project-recovery:view-any Retrieve how many self-service Disaster Recoveries of each kind the creator the token acts for may still run, what support has released on top, and when the allowance returns.
  • get_recovery_readiness — Get Recovery Readiness — GET /v1/recovery/readiness · project-recovery:view-any Retrieve the Disaster Recovery readiness checklist for the creator the token acts for: every line with its state, whether the plan locks it, and the totals.
  • get_recovery_roll_call — Get Recovery Roll Call — GET /v1/recovery/operations/{operation}/roll-call · project-recovery:view Retrieve where the re-admission after one Disaster Recovery operation stands: members re-admitted, joined, still outside, and whether a reminder may go out now.
  • get_recovery_settings — Get Recovery Settings — GET /v1/projects/{project}/recovery/settings · project-recovery:view Read one project's Disaster Recovery settings — automatic failover and its fee consent, how members are told after a swap, and whether a standby installation is kept.
  • get_resource_standby — Get Resource Standby — GET /v1/projects/{project}/resources/{resource}/standby · project-recovery:view Read the standby kept for one resource — its health, whether posts are mirrored into it, and when it was last probed and written to.
  • list_recovery_incidents — List Recovery Incidents — GET /v1/recovery/incidents · project-recovery:view-any List the Disaster Recovery incidents of the creator the token acts for — what the health probes found broken, open by default — with the reason in the connector's words.
  • list_recovery_operations — List Recovery Operations — GET /v1/recovery/operations · project-recovery:view-any List every Disaster Recovery operation of the creator the token acts for — run by the creator, the platform or on demand — with its state and whether it can still be undone.

Referral Affiliates (2)

  • find_referral_affiliates — Find Referral Affiliates — GET /v1/projects/{project}/referral-affiliates · project-referral:view-any List the members enrolled in a project's Referral Program, newest first, optionally narrowed by status or to one member. A list row never carries the per-currency balances; use Get Referral Affiliate for what one affiliate is owed. Payout details an affiliate typed are never returned.
  • get_referral_affiliate — Get Referral Affiliate — GET /v1/projects/{project}/referral-affiliates/{affiliate} · project-referral:view Retrieve one affiliate by UUID with their code, status, days balance and "balances" per currency: pending (inside the hold), earned, payable (what Record Referral Payout may record) and paid out, each a decimal string. The payout details they typed are never returned.

Referral Payouts (1)

  • find_referral_payouts — Find Referral Payouts — GET /v1/projects/{project}/referral-payouts · project-referral:view-any List the payouts recorded against a project's affiliates, newest first: how much was paid, in which currency, the creator's reference and note, and how many commissions each payout covered. Narrow to one affiliate.

Referral Program (1)

  • get_referral_program — Get Referral Program — GET /v1/projects/{project}/referral-program · project-referral:view Retrieve a project's Referral Program: what referrers earn, what their friends receive, who may join, the hold before a commission is payable and the plans a conversion counts on. Returns no rows while the project has no programme. "plan_ids" empty means every plan, not no plans.

Referral Rewards (1)

  • find_referral_rewards — Find Referral Rewards — GET /v1/projects/{project}/referral-rewards · project-referral:view-any List the referral ledger, newest first: one row per settled payment per side of a referral, with the days or money it earned, whose it is and where it stands. Narrow by affiliate, status (pending, approved, paid, applied, reversed) or beneficiary (referrer, friend). A reversal is its own row with a negative amount.

Referrals (2)

  • find_referrals — Find Referrals — GET /v1/projects/{project}/referrals · project-referral:view-any List the friends affiliates brought in, newest first: how each arrived, whether their first payment settled and until when the affiliate earns on them. Narrow by status, affiliate or "since", the earliest arrival to include, so a scheduled Zap can page only what happened since its last run.
  • get_referral — Get Referral — GET /v1/projects/{project}/referrals/{referral} · project-referral:view Retrieve one referral by UUID: the affiliate, the friend's member id, how they arrived, whether their first payment settled and "commission_ends_at", the instant the affiliate stops earning on them on a programme with a period.

Resources (2)

  • get_resource — Get Resource — GET /v1/projects/{project}/resources/{resource} · project-resource:view Retrieve a single project resource by UUID: its kind (manual or connector:kind), connector, the place it is bound to, title, description and switch.
  • list_resources — List Resources — GET /v1/projects/{project}/resources · project-resource:view-any List every resource attached to a project, or only those of one kind (manual, telegram:channel) or on one connector.

Retention (5)

  • find_cancellation_feedback — Find Cancellation Feedback — GET /v1/projects/{project}/retention/cancellations · project-subscription:view-any List the cancellation screens a project's members reached, newest first: the member, the plan, the reason they gave, their own words, the offer shown and whether they took it, and where they answered. Narrow by reason or by the surface they answered on.
  • find_checkouts — Find Checkouts — GET /v1/projects/{project}/retention/checkouts · project-subscription:view-any List the checkouts a project's members started on the portal or in the project bot, newest first: the member, the plan they were buying, the rail and where they started, when it started, when the hourly sweep counted it as stalled and when a payment finished it, summed up as an outcome. Narrow to the stalled or the recovered ones, one plan or one member.
  • find_retention_activity — Find Retention Activity — GET /v1/projects/{project}/retention/activity · project-subscription:view-any List a project's Revenue Recovery ledger, newest first: one row per notice, offer, feedback and win-back message the programme sent, with the member, the channel that carried it, the coupon and the sequence step behind a win-back message, and whether a charge settled for the member afterwards. Narrow to one kind of row.
  • get_retention_settings — Get Retention Settings — GET /v1/projects/{project}/retention · project-subscription:view Retrieve a project's Revenue Recovery settings: the grace window a failed renewal keeps access for (with the notice ladder in words), the daily digest, the cancellation question, the three offers the cancellation screen can make, the checkout window after which a checkout counts as stalled and the trial reminder before a cardless trial ends. The row is created with the defaults on the first read.
  • get_retention_stats — Get Retention Stats — GET /v1/projects/{project}/retention/stats · project-subscription:view-any Read what Revenue Recovery did on a project over a period: the failed renewals, reminders, pauses, recoveries with what they brought back in US dollars, restorations, win-back messages and members won back, the cancellation screens with the offers shown and taken, why members cancelled, and the leads, checkouts and trials the sequences nurtured with what the recovered checkouts were worth. The members in grace and paused right now ignore the period.

Roles (2)

  • get_role — Get Role — GET /v1/roles/{role} · role:view Retrieve a single role by UUID.
  • list_roles — List Roles — GET /v1/roles · role:view-any List every role defined for the current team.

Sequences (3)

  • find_sequence_enrollments — Find Sequence Enrollments — GET /v1/projects/{project}/sequences/{sequence}/enrollments · project-sequence:view-any List the passages members made through one recovery sequence, newest first: when they entered, the step due next, and how the passage ended if it has (won back, unreachable, the sequence switched off or deleted). Narrow to passages that ended one way.
  • find_sequences — Find Sequences — GET /v1/projects/{project}/sequences · project-sequence:view-any List a project's recovery sequences, newest first, each with its steps in order and how it has done: the members enrolled, still receiving steps, completed and won back. Narrow to running or paused sequences, or to one trigger.
  • get_sequence — Get Sequence — GET /v1/projects/{project}/sequences/{sequence} · project-sequence:view Retrieve one recovery sequence by UUID: its name, trigger, switch, its steps in order with the coupon each carries, and how it has done. Find Sequence Enrollments has the members behind the counts.

Subscriptions (3)

  • find_subscription_by_id — Find Subscription by ID — GET /v1/subscriptions/{subscription} · project-subscription:view Look up a subscription by its UUID. Useful for follow-up steps after a subscription webhook fires.
  • list_subscription_grants — List Subscription Grants — GET /v1/subscriptions/{subscription}/grants · project-subscription:view List the access grants a subscription holds: one per resource (and per pass window), with the connector, how access was given, where it stands and why it failed if it did.
  • list_subscriptions — List Subscriptions — GET /v1/subscriptions · project-subscription:view-any List subscriptions, optionally filtered by status or plan.

Support Canned Replies (2)

  • find_canned_replies — Find Canned Replies — GET /v1/projects/{project}/support/canned-replies · support-canned-reply:view-any List the saved replies in a project's support picker, in picker order.
  • get_canned_reply — Get Canned Reply — GET /v1/projects/{project}/support/canned-replies/{reply} · support-canned-reply:view-any Retrieve one saved support reply by UUID.

Support Conversations (3)

  • find_support_conversation — Find Support Conversation — GET /v1/support/conversations/{conversation} · support-conversation:view Fetch a single support conversation by ID.
  • list_support_conversations — List Support Conversations — GET /v1/support/conversations · support-conversation:view-any List support conversations, newest activity first, optionally filtered by project, status or assignee.
  • list_support_messages — List Support Messages — GET /v1/support/conversations/{conversation}/messages · support-conversation:view List the messages in a support conversation, oldest first. This is where the message bodies live — the Support Message Received trigger deliberately omits them so member text never lands in webhook logs. Internal notes are only returned when the token can also write to the conversation.

Support Settings (1)

  • get_support_settings — Get Support Settings — GET /v1/projects/{project}/support/settings · project:view Read a project's support inbox settings: whether support is on, where new threads are relayed, the agent name, the auto-reply and email notifications. The relay chat id is never exposed.

Team Members (2)

  • get_team_member — Get Team Member — GET /v1/teams/{team}/members/{member} · team-member:view Retrieve a single team member by team ID + user ID.
  • list_team_members — List Team Members — GET /v1/teams/{team}/members · team-member:view-any List every collaborator attached to a team.

Teams (3)

  • get_current_team — Get Current Team — GET /v1/teams/current · team:view Retrieve the team the authenticated token is scoped to.
  • get_team — Get Team — GET /v1/teams/{team} · team:view Retrieve a single team by UUID.
  • list_teams — List Teams — GET /v1/teams · team:view-any List every team the authenticated user belongs to.

Tokens (2)

  • get_token — Get Token — GET /v1/tokens/{token} · token:view Retrieve metadata for a single personal access token by UUID.
  • list_tokens — List Tokens — GET /v1/tokens · token:view-any List every personal access token issued for the authenticated user / team.

Webhook Deliveries (2)

  • get_webhook_delivery — Get Webhook Delivery — GET /v1/webhook-deliveries/{delivery} · webhook-delivery:view-any Retrieve one outbound webhook delivery by UUID: its event, status, attempts, the payload that was posted and what the endpoint answered.
  • list_webhook_deliveries — List Webhook Deliveries — GET /v1/webhook-deliveries · webhook-delivery:view-any List the team's outbound webhook delivery log, newest first — what was posted, what the endpoint answered and where each row is on the retry ladder. Narrow by status to find the failed or dead-lettered rows worth retrying.

Webhook Endpoints (2)

  • get_webhook_endpoint — Get Webhook Endpoint — GET /v1/webhook-endpoints/{endpoint} · webhook-endpoint:view Retrieve one of the team's outbound webhook endpoints by UUID. The signing secret is never returned; it exists in the create and rotate-secret responses only.
  • list_webhook_endpoints — List Webhook Endpoints — GET /v1/webhook-endpoints · webhook-endpoint:view-any List every webhook endpoint registered for the team.

Recipes

Prebuilt Zap ideas combining Subscriby triggers with common downstream apps. Swap the destination for whatever CRM, spreadsheet, or messaging tool fits your stack.

Revenue ops

New subscriber → welcome email

  • Trigger: subscription.created on project X.
  • Action: Mailjet / Resend / Postmark → send a "Welcome" email using the subscriber's email field. Most members have no email — they join through a bot and are never asked for one. billing_email is often the only address on file, and it is unverified, so treat it as identification rather than a consented mailing address.

New subscriber → CRM upsert

  • Trigger: subscription.created.
  • Action: HubSpot / Pipedrive / Attio → create-or-update contact; tag with plan name + initial MRR.

Churn → Slack alert

  • Trigger: subscription.cancelled or subscription.expired.
  • Action: Slack → post in #churn-watch with subscriber handle, plan, and days-subscribed.

Failed payment → Slack + follow-up email

  • Trigger: payment.failed.
  • Action 1: Slack → post in #revenue-ops.
  • Action 2: Delay 12 hours, then run the find_subscription_by_id search. If the next retry hasn't cleared the state, fire a Mailjet reminder with a one-tap link to update the payment method.

Past due → automated drip

  • Trigger: subscription.past_due.
  • Action: Mailjet sequence — day 1 "payment failed", day 3 "reminder", day 7 "last chance".

Trial converting → personal nudge

  • Trigger: subscription.trial_converting.
  • Action: Slack DM to the creator with a link to the subscriber's profile so they can intervene before the trial flips to paid.

Access codes

Access-code batch generated → Airtable export

  • Trigger: access_code.generated.
  • Action: Airtable → append a row with batch metadata (plan, count, expiry).

Access-code redeemed → Google Sheet log

  • Trigger: access_code.redeemed.
  • Action: Google Sheets → append a row with subscriber id, plan id, masked code, timestamp.

Gift campaign → generate + DM

  • Trigger: New row in an Airtable "Influencer List".
  • Action 1: bulk_generate_access_codes (1 code, export_type=file).
  • Action 2: get_deep_link with access_code=<code> to build a one-tap bot link.
  • Action 3: Slack DM / email the influencer with the link.

Team + audit

Member banned → Telegram ops chat

  • Trigger: member.banned.
  • Action: Telegram → send to an ops chat with reason + the ban-issuing admin's name.

Team role changed → audit trail

  • Trigger: team.member.role_changed.
  • Action: Notion database → append an entry with old/new role, actor, timestamp.

Suspicious activity → auto-revoke token

  • Trigger: list_activity search on an hourly schedule, filter for actor_kind = 'mcp' entries touching high-value resources.
  • Action: If count exceeds your threshold, call revoke_token on the flagged token id and post the incident to Slack.

Billing

Grace-period warning → creator heads-up

  • Trigger: billing.grace_period_warning.
  • Action: Email the account owner with a link to /settings/billing before the grace window elapses.

Account locked → ops escalation

  • Trigger: billing.account_locked.
  • Action 1: PagerDuty → incident.
  • Action 2: Slack → post in #oncall with the tier cycle and last successful payment date.

Tier upgraded → CRM annotation + welcome pack

  • Trigger: billing.tier_upgraded.
  • Action 1: HubSpot → update lifecycle stage to "paid".
  • Action 2: Loom or Notion → send the creator the tier-specific onboarding playbook.

Analytics & reporting

Weekly revenue digest

  • Trigger: Schedule — every Monday 09:00.
  • Action 1: get_dashboard_metrics with period=7d.
  • Action 2: get_transaction_breakdown with dimension=payment_provider, period=7d.
  • Action 3: Email / Slack a digest combining both.

Plan performance → Google Sheet

  • Trigger: Schedule — daily.
  • Action 1: get_plan_performance for each active project.
  • Action 2: Google Sheets → append rows (one per plan) for the dashboard you hand to finance.

Month-end close → earnings statement

  • Trigger: Schedule — 1st of each month 06:00.
  • Action 1: get_earnings_report with granularity=day for the previous month.
  • Action 2: Generate a PDF via DocRaptor and email it to accounting@yourco.

Integrations hygiene

Onboarding checklist

  • Trigger: member.trial_joined.
  • Action 1: HubSpot → start "Trial onboarding" sequence.
  • Action 2: Delay 3 days.
  • Action 3: find_member_by_id to check status; if still trialing, send a reminder.

Test webhook endpoint on deploy

  • Trigger: GitHub Actions → new release published.
  • Action: test_webhook_endpoint against every active endpoint in your team. Post a summary in Slack.

Rotate webhook secret → secret manager

  • Trigger: Schedule — every 90 days.
  • Action 1: rotate_webhook_secret on the endpoint.
  • Action 2: Write the fresh secret into HashiCorp Vault / AWS Secrets Manager / 1Password.
  • Action 3: Slack → notify #platform that the rotation landed.

Troubleshooting

SymptomLikely causeFix
Test-auth returns 401 AUTHENTICATION_REQUIREDToken expired or revokedMint a new token
Test-auth returns 403 TOKEN_MISSING_ABILITYToken lacks team:viewMint with team:view plus the specific abilities each trigger / action / search needs
Test-auth returns 404 TENANT_MISMATCHToken has no scope:team:<uuid> entryMint from the dashboard — the UI always appends the scope automatically
performSubscribe returns 422 VALIDATION_FAILED on events.*.inEvent name typo / outdatedRebuild the Zap; the Zapier app is kept in lockstep with the webhook catalog
Zap receives no eventsEndpoint auto-disabled after consecutive failuresRe-enable from /settings/webhooks or use the test_webhook_endpoint action for a diagnostic ping
Analytics search returns 400 VALIDATION_FAILED on dimensionget_transaction_breakdown requires plan / payment_provider / currency / projectPick one of the four

Source

The Zapier app is maintained at github.com/envigo-innovations/subscriby-zapier. PRs welcome. See the CHANGELOG for per-version event / action / search deltas.

How is this guide?

Last updated on

On this page

InstallTriggersHow triggers work1You pick a trigger in Zapier2Subscriby registers the endpoint3Event fires inside Subscriby4You turn the Zap offActionsAccess Codes (2)Account (4)Broadcasts (1)Coupons (5)Creator Tasks (1)Groups (4)Links (3)Members (4)Pass Windows (3)Payment Methods (4)Plans (6)Projects (12)Recovery (12)Referral Affiliates (3)Referral Payouts (1)Referral Program (4)Resources (7)Retention (1)Roles (3)Sequences (3)Subscriptions (6)Support Canned Replies (3)Support Conversations (6)Support Settings (1)Team Members (4)Teams (3)Tokens (1)Webhook Deliveries (2)Webhook Endpoints (6)Notes on specific actionsPlanPlan Kind — a breaking change in 3.0.0Building a Pass SeriesRecoveryBroadcastChoosing the audienceTeam + RBACSearchesAccess Codes (2)Account (7)Activity (1)Analytics (8)Connectors (2)Coupons (2)Creator Tasks (1)Distribution (2)Groups (2)Links (3)Members (4)Pass Windows (2)Payment Methods (2)Plans (3)Projects (6)Recovery (7)Referral Affiliates (2)Referral Payouts (1)Referral Program (1)Referral Rewards (1)Referrals (2)Resources (2)Retention (5)Roles (2)Sequences (3)Subscriptions (3)Support Canned Replies (2)Support Conversations (3)Support Settings (1)Team Members (2)Teams (3)Tokens (2)Webhook Deliveries (2)Webhook Endpoints (2)RecipesRevenue ops1New subscriber → welcome email2New subscriber → CRM upsert3Churn → Slack alert4Failed payment → Slack + follow-up email5Past due → automated drip6Trial converting → personal nudgeAccess codes1Access-code batch generated → Airtable export2Access-code redeemed → Google Sheet log3Gift campaign → generate + DMTeam + audit1Member banned → Telegram ops chat2Team role changed → audit trail3Suspicious activity → auto-revoke tokenBilling1Grace-period warning → creator heads-up2Account locked → ops escalation3Tier upgraded → CRM annotation + welcome packAnalytics & reporting1Weekly revenue digest2Plan performance → Google Sheet3Month-end close → earnings statementIntegrations hygiene1Onboarding checklist2Test webhook endpoint on deploy3Rotate webhook secret → secret managerTroubleshootingSourceRelated

Subscriby is a product
designed by you — for you.
No boardroom full of executives deciding what we ships next. Our roadmap always shaped by you with your feedback.

Share feedback or a request

For AI agents: llms.txt · llms-full.txt