Webhooks let Appstle Memberships tell another system, such as your own server, a CRM or an automation tool, when something happens to a membership. Appstle sends a message to the web address you choose each time a membership is created, changed, paused, cancelled or billed. Use them to keep customer records in sync, start your own follow-up emails, or give and remove access to content outside Shopify.

Webhooks are a developer feature. Whoever builds the receiving end needs the technical guide: Appstle Memberships webhook events and setup.

If you would rather react to memberships inside Shopify with no code, use Shopify Flow instead. The same events reach it when you turn on Shopify Flow under More → App Integrations & Exports → App Integrations. Shopify Flow works on every Appstle Memberships plan and doesn’t need webhooks turned on.

Availability: webhooks are included in the Enterprise and Enterprise Plus plans. On other plans the Membership Webhook Integration page shows an add-on offer and a Chat with us link, and there is no Enable Webhook button until the feature is switched on for your store.

Set up webhooks

Turn on webhooks in the app

In your Shopify admin, open Apps → Appstle℠ Memberships.
Click More, then under General Settings click Membership Webhook Integration.
Click Enable Webhook at the top right.

The page now shows a Launch webhook portal button, and the top button reads Disable Webhook. The View tutorial button opens this article.

Add an endpoint in the webhook portal

Click Launch webhook portal. The portal opens in a new tab.
Click Add Endpoint.
In Endpoint URL, enter the HTTPS address of your server.
Optional: in Description, write what the endpoint is for, for example “Order system”.
Under Subscribe to events, tick the events this endpoint should receive. If you tick none, the form reads “Receiving all events” and the endpoint gets every event, including membership.swap-product, which the list doesn’t show.
Click Create.

The new endpoint’s page opens. Click the eye icon under Signing Secret to see the key your server uses to check each message. Message Attempts lists what was sent to this endpoint, and the Replay menu resends messages.

An endpoint receives events from the moment you click Create. To stop all messages, click Disable Webhook in the app. Your endpoints stay in the portal. Events that happen while webhooks are off are not sent later.

See what Appstle sent

Logs, in the portal’s left menu, lists every message Appstle sent for your shop, newest first, with its event type and message ID. Messages show there even when no endpoint was set up to receive them. Activity shows how many delivery attempts succeeded or failed, and Event Catalog describes each event you can tick for an endpoint.

Events Appstle sends

Appstle can send the eleven events below. Each message is an HTTP POST with a JSON body that holds the event name in type and the details in data.

membership.created: A new membership starts, because a customer buys a membership plan or you add one with Create Membership.
membership.updated: A membership changes, for example its plan, product, price, next billing date or status. Appstle sends this event together with the more specific event for the same change, such as membership.paused, and after each successful renewal, because the next billing date moves forward.
membership.swap-product: The products in a membership change: a product or variant is swapped, added or removed, for example by Product Swap Automation at a renewal. Appstle also sends membership.updated for the same change. The portal’s event list doesn’t include this event, so you can’t tick it. To get it, leave every event unticked so the endpoint receives all events.
membership.activated: A membership’s status changes to active, for example when a paused membership is resumed.
membership.paused: A membership’s status changes to paused, including when Appstle pauses a membership after its last billing cycle.
membership.cancelled: A membership’s status changes to cancelled, whether you, the member or Failed Payment Recovery cancelled it.
membership.expired: A paused or cancelled membership loses its perks, because Appstle removes its customer tag. That happens when the period the member paid for ends, or at once when perks are revoked immediately (see Shop Settings). A membership that Appstle pauses after its last billing cycle counts too. If the customer has another active membership with the same tag, the tag stays and this event isn’t sent. Appstle also sends it as soon as Failed Payment Recovery cancels or pauses a membership.
membership.next-order-date-changed: The next billing date of a membership is changed, for example when you or the member reschedule it. When the date moves forward after a renewal, only membership.updated is sent.
membership.billing-interval-changed: The billing frequency of a membership is changed, for example from monthly to yearly. It can also arrive twice for one change, or when the plan changed but the frequency didn’t, so compare billingPolicy with the value you stored.
membership.billing-success: A renewal payment for a membership succeeds. The first payment, at checkout, doesn’t send it: membership.created covers that.
membership.billing-failure: A renewal payment for a membership fails, including each failed retry by Failed Payment Recovery.

All events except the two billing events carry the full membership: its status, billing and delivery rules, products, discounts and the order that started it, plus the customer’s contact details, delivery address and a masked summary of their payment method.

The billing events carry the billing attempt: the membership it belongs to, its status, date and order and, for a failure, the reason and whether Appstle will retry. For example payloads, see Appstle Memberships webhook events and setup.

Things to know

One change can send several events, and they don’t always arrive in the order the changes happened. For example, when Failed Payment Recovery cancels a membership, membership.expired can arrive before membership.cancelled.
A message can arrive more than once. A retry keeps the same ID in the svix-id header, so skip an ID you have already handled. Appstle can also send one change as two messages with different IDs, so make sure that handling an event twice does no harm.
Appstle retries a message automatically when your endpoint doesn’t answer with a success code, so reply quickly and do the heavy work afterwards. You can also resend messages from the endpoint’s page in the portal. Message contents are kept for 30 days, so resend within that time.
Check the signature on every message before you trust it. Each endpoint’s Signing Secret is on its page in the portal, and the technical guide shows how to check the signature.

Troubleshooting

If messages don’t arrive or don’t look right, find what you see in the table below.

What you see	What to check
There is no Enable Webhook button.	Your plan doesn’t include webhooks yet. The page shows the add-on offer. Click Chat with us to have it switched on.
The page says “Enable to see the Webhook dashboard.”	Click Enable Webhook. If the top button already reads Disable Webhook, reload the page. If Launch webhook portal still doesn’t appear, contact Appstle support.
Your server gets no events.	Check that the button reads Disable Webhook, that the endpoint is saved in the portal with the right events, and that its address is public and starts with https.
You’re not sure whether Appstle sent an event.	Open the membership from Memberships and click the Activity Logs tab. Each message Appstle sends, to the portal or to Shopify Flow, adds a Webhook entry. If there is none at the time of the change, check that webhooks were on then. The portal’s Logs page lists every message too.
You get a cancellation but no expiry event.	`membership.expired` comes when the member loses perks: at the end of the period they paid for, unless perks are revoked immediately. If the customer has another active membership with the same tag, the tag stays and the event isn’t sent.
The portal shows failed deliveries.	Open the failed message in the portal to see your server’s answer. Fix the endpoint, then resend the message.
The signature check fails.	Use the Signing Secret of the same endpoint, and verify the raw request body before it is parsed as JSON.
You get the same event twice.	If both messages have the same `svix-id`, the second is a retry: skip it. If the IDs differ, compare the data with what you stored and do nothing when nothing changed.