Skip to main content
Webhooks are a way for your app to receive live notifications of activity on your user’s accounts.
The flat platform events listed below are deprecated in favour of the creator.* events, which use one consistent Standard-Webhooks envelope and carry richer payloads. The legacy events continue to fire during the migration window, so existing integrations keep working — but new integrations should use creator.*. See Migrating from the legacy events.
The legacy event types (deprecated):
If the creator has Fanvue Checkout enabled, your app can subscribe to the checkout webhooks (checkout_link.*, payout.paid) from the same Events tab described below. They require the read:creator scope and are delivered with a Standard-Webhooks envelope (branch on data.object). Your app’s own sales (purchases, subscriptions, refunds, disputes) are covered by the App Webhooks (app.*), configured from the same Events tab and gated on the read:self scope.
Bundled vs separate subscription and payment. The legacy subscription.new event bundles the subscription detail and the payment (price, transactionOrderId, transactionOrderStatus) into one payload. On the newer envelope (creator.*) and checkout events, the subscription and the payment arrive as separate events that you correlate yourself; checkout links them via the subscription uuid.

Setting up a webhook

  1. Set up an endpoint on your backend to receive webhooks. It should accept POST requests from our API and return a 2xx response.
  2. Navigate to the Fanvue Developer Area, select your app and open the Events tab. Events tab
  3. Click Add Webhook. In the dialog, enter your Endpoint URL and select the events you want this endpoint to receive. Use Select All to subscribe to every event, or tick individual events. A single endpoint can listen for multiple events. Add Webhook dialog
  4. Click Save. The webhook is created and appears in the Events & Endpoints list, where you can enable or disable it with the toggle.
Each webhook event requires certain OAuth scopes to work. Enable the required scopes in the Authentication tab. See Required scopes per event for the full mapping.

Missing scope warnings

Different webhook events require different OAuth scopes. For an event to be delivered, your app must have the scopes that event needs enabled in the Authentication tab, under Define permissions. If a webhook needs scopes that your app does not yet have, the Events tab shows a warning that the required consents are missing. Enable the relevant scopes in the Authentication tab to clear it. Authentication permissions Note that adding a scope to your app is not enough on its own for already-connected users: creators who authorized your app before the scope was added must re-authorize it before those events will be delivered. See Re-authorize the app after scope changes.

Managing and testing webhooks

Each webhook in the Events & Endpoints list has an actions () menu:
  • Edit, change the endpoint URL or the events it subscribes to.
  • Test, send a sample payload to your endpoint so you can confirm it is reachable and that your signature verification works, without waiting for a real user action.
  • History, review recent delivery attempts for the webhook.
  • Delete, remove the webhook.
Webhook actions menu

How deliveries work

  • Each webhook is delivered as an HTTP POST with Content-Type: application/json.
  • The request body contains an event-specific JSON payload.
  • Your endpoint should return a 2xx response as soon as you successfully receive and persist the event.
  • Delivery is at least once: a failed attempt is retried up to 5 times, so expect duplicates. Each payload carries an eventId for deduplication.
On message.read the eventId is not unique per event — every read receipt in the same conversation carries the same value, so deduplicating on it alone keeps only the first. See Delivery, Retries and Idempotency for the safe key. Every other flat event carries a per-event eventId.
For timeouts, the retry schedule, endpoint auto-disable, and deduplication, see Delivery, Retries and Idempotency.
A single creator-tenant subscription can deliver both these platform event webhooks and the Fanvue Checkout webhooks (checkout_link.*, payout.paid) to the same endpoint; you receive an event only if your subscription includes that event type. Branch on the event type to tell them apart (and on data.object for checkout events, which use a Standard-Webhooks envelope rather than the flat payloads above).

Verifying webhook signatures

Every webhook request includes an X-Fanvue-Signature header (format t=<timestamp>,v0=<signature>). Verify it on every request so forged or replayed events are rejected before you act on them. Your app’s signing secret is shown in the Events tab of the Developer Area (the View signing secret action). That one secret signs every delivery for webhooks you added in the Developer Area. Webhooks registered through the API with POST /webhooks/subscriptions are different: each subscription gets its own secret, returned as signingSecret in the create response and not retrievable afterwards. See Verify Webhook Signatures for the header breakdown, both signing-secret paths, the step-by-step verification flow, and complete Node and Python samples.

Testing locally

  • Expose your local server with a tunneling tool (for example, ngrok) and copy the public HTTPS URL.
  • Add a webhook in the Events tab with that URL and the events you want to receive.
  • Use the Test action in the webhook’s menu to send a sample payload to your endpoint, or trigger the event in a test environment, then inspect the request reaching your server.

Troubleshooting: test events work, but production events do not

If webhook test deliveries succeed but real user activity does not trigger events, use this checklist.

1) Confirm required OAuth scopes are enabled for each event

2) Confirm the webhook event checkbox is enabled

In your app’s Webhooks tab, verify the event type is selected for the webhook endpoint you configured.

3) Re-authorize the app after scope changes

If scopes were added after users already connected your app, previously granted consent may not include those scopes yet.
  1. Open https://fanvue.com/settings/account/third-party-apps
  2. Revoke access for your app
  3. Reconnect the app and approve the requested scopes again

4) Validate with a real production action

Use an actual follow, purchase, subscription, tip, or message event from a separate account and verify delivery on your endpoint logs.

Example endpoint (Node.js / Express)