Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.getmembrane.com/llms.txt

Use this file to discover all available pages before exploring further.

Internal Events let Membrane know when something happens in your app. They can be used to trigger Flows using Internal Event Trigger.

​
Internal Event Types

To use Internal Events, you need to define one or more Internal Event Types. You can do it on the Internal Event Types page. Each Internal Event Type has:
  • Schema – a Data Schema describing the event’s contents.
  • Example – an example of the event’s contents matching the Schema. You can use Example to generate schema.

​
Sending Events to Membrane

​
Global Webhook

Use Global Webhook to send internal events to Membrane in a centralized (not per-user) way. Simply make an HTTP request of any type to the webhook URI and the event will be captured and processed. 
curl --request POST \
  --url https://api.integration.app/{GLOBAL_WEBHOOK_URI} \
  --header "Authorization: Bearer {CUSTOMER_TOKEN}" \
  --header "Content-Type: application/json" \
  --data '{"eventType": "order.created", "orderId": "123"}'
Associating Events with Tenants When you send an event to the Global Webhook, Membrane needs to know which tenant the event belongs to. There are three ways to specify this, in order of priority:
  1. Authentication Token (Recommended) – Include the tenant’s authentication token in the Authorization header. Membrane will automatically extract the tenant ID from the token.
  2. Tenant ID Formula – Configure a formula in the Internal Event Type settings that extracts the tenant ID from the event payload. This is useful when you cannot include an authentication token in the request.
  3. User ID Formula (Legacy) – For backward compatibility, you can use the older “User ID Formula” field which works the same way as Tenant ID Formula.
If none of these methods provide a tenant ID, the event will be rejected.

​
Per-Tenant Subscriptions

If instead of a Global Webhook, you want to use per-user webhooks or if you already have an API that allows per-user event subscriptions, you can configure subscriptions for your Internal Event. When configured, Membrane:
  1. Makes an HTTP request to your application’s subscription API
  2. Provides a unique webhook URL in the request (available as {{webhookUri}} variable)
  3. Expects your application to send events to that specific webhook URL
  4. Tracks the subscription request and response for troubleshooting
You can use Tenant Fields and webhookUri variables to configure the request. The request will be called the first time this Internal Event Type is used for a given User. You can find the subscription request and response, as well as other information about subscriptions on the Subscriptions page.

​
Batch Events

If the body of the request your app sends to Membrane is an array, it will be treated as multiple events. For global webhooks with batch events, each event can be associated with a different tenant by including tenant identification in each event payload.

​
How Subscriptions Work

Internal event subscriptions are created when a Flow has a trigger that reacts to Internal Events and the flow is enabled. When you enable a Flow that uses an Internal Event Trigger node, Membrane automatically:
  1. Creates an Internal Event Subscription for the specified Internal Event and Tenant.
  2. If configured, makes an HTTP subscription request to your application’s API.
  3. Generates a unique webhook URL for receiving events.
The subscription is automatically disabled (and unsubscribed) when there are no more flows that need it.

​
Automatic De-duplication

Membrane automatically de-duplicates subscriptions. If multiple Flow Instances need the same Internal Event Type for the same tenant and instance key, only one subscription is created and shared between them. For example:
  • Flow A and Flow B both trigger on “Order Created” events for Tenant X
  • Only one Internal Event Subscription is created
  • Both flows are launched when an event arrives
  • The subscription remains active until both flows are disabled

​
Monitoring and Troubleshooting

​
Viewing Subscriptions

Navigate to Internal Event Subscriptions to see:
  • All active and inactive subscriptions
  • Subscription status (subscribed/unsubscribed)
  • The webhook URL for each subscription
  • Subscription and unsubscription request/response history
  • Associated Internal Event Type and tenant

​
Viewing Events

Navigate to Internal Events to see:
  • All received events
  • Which subscription received each event
  • Event payload and timestamp
  • Which Flows were triggered
  • Execution status of triggered Flows

​
Flow Was Not Launched

If you expected a webhook to launch a flow, but it didn’t: Step 1: Check Logs Go to the Webhook Logs and check if the events you expected are there. Use filters to narrow down the list. If you found the record, check its details:
  • Is it associated to the correct App User?
  • Does it have the data you expected?
Step 2: Check Flow Node Configuration If you found the event in logs but it didn’t trigger the expected flow:
  • Does the trigger use the right webhook? Check node dependencies on the Flow Instance page.
  • Does it have a filter that excludes the event?

​
Webhook Events Do Not Appear in Logs

Step 1: Check Subscription If you are using a webhook with subscription, find the subscription by Webhook and User, and check its status. Is it subscribed successfully? Step 2: Trigger the Webhook Manually Make an HTTP request to the webhook URL:
  • If using a subscription – find the webhook URL on the corresponding subscription page.
  • If not – use the URL from the webhook page.

​
Webhook Subscription Is Not Created

Find it on the Subscriptions page and check the latest request and response. If everything looks correct, the problem is likely on your app’s side. You can try deleting the subscription and creating it again to troubleshoot.