Torii Membership System

Webhooks

An automation in your CRM can do more than send emails. At any step, it can tell your membership site to act: create this member, sync that one's tags, provision a customer's whole team. The messenger is a webhook, a URL your CRM calls while the automation runs.

Member operations

Create member

https://YOURSITE.com/?operation=create_member&membauth=YOUR_AUTH_KEY

Fires the moment someone should have an account: right after a purchase or a free registration. The account is created in WordPress, and no password is generated or stored anywhere, so plan to get the member in with a magic link rather than a credentials email. The full recipe, end to end, is the Provisioning New Members guide.

Update member

https://YOURSITE.com/?operation=update_member&membauth=YOUR_AUTH_KEY

Pushes a contact's current state down to the site: new tags, changed fields. Run it whenever your CRM changes something the member's access depends on, like applying a membership tag after an upgrade.

https://YOURSITE.com/?operation=get_magiclink&membauth=YOUR_AUTH_KEY

Generates a fresh magic link for an existing member and writes it to their CRM contact field. This is the resend path: wire it into any re-engagement or "resend my access" automation, wait a minute, then send the email.

Tag member and delete member

tag_member applies tags from the payload without touching other fields; delete_member removes the WordPress account. Use them where your automation's intent is narrower than a full update.

Group operations

The Group Accounts module registers four more operations on the same URL pattern: create_group, update_group, deactivate_group, and delete_group. The webhook contact becomes the group owner, and the group's attributes (name, seats, end date, access tags, status) come from URL parameters or the CRM contact fields you map in the module's webhook settings. The full walkthrough is the Setting Up Group Accounts guide.

Native member updates

The operations above carry a CRM payload: your connector decodes the contact and maps its fields and tags. The update_member_data operation carries a payload that already speaks Torii, with a WordPress user ID or email and your local field slugs and tag IDs. Nothing to decode means no connector is required, so Zapier, n8n, Make, and scripts can drive it directly. See Native Webhooks.

The three ingredients

Whatever CRM you use, the recipe is the same:

  1. A trigger. Usually the purchase or form submission that starts the member's journey.
  2. An HTTP POST action. Every automation builder has one; it goes by slightly different names in each CRM.
  3. The URL and auth key. Replace YOURSITE with your domain and YOUR_AUTH_KEY with a webhook secret key from your Torii settings. Once a key is saved, the settings screen shows both URLs ready to copy.

Guides by CRM

For the other connectors, the operations and URLs above are identical; only the automation builder's screens differ. If your CRM's automation can POST a URL, it can drive these.

One timing note that applies everywhere: if an automation creates a member and then emails them a magic link, put a short wait (a minute is plenty) between the webhook and the email. The webhook needs time to generate the link before the email goes out.

These automation URLs run one request at a time, synchronously. The notifications your CRM generates on its own when contacts change are handled differently: acknowledged instantly and applied in the background. See Advanced Webhook Handling.