Skip to main content
creator.* webhooks notify your backend in real time about activity across a creator’s Fanvue account: on-platform payments, profile and fan-experience subscriptions, direct messages, post and message engagement, refunds, disputes, and fan mute and presence changes. They are the successor to the older flat platform events (purchase.new, subscription.new, message.received, and so on). Unlike the checkout webhooks, which are scoped to a creator’s checkout-link sales, creator.* events cover the creator’s whole platform feed. Each event carries the OAuth scope your app must hold to receive it, see Available events.
creator.* events replace the legacy flat platform events (New Follower, Purchase Received, Message Received, and so on). The legacy events are deprecated but continue to fire during the migration window, so existing integrations keep working. New integrations should use creator.*. See Migrating from the legacy events.

​
Setting up and verifying

Setup, testing, and signature verification are the same as for every Fanvue webhook:

​
Amounts and currency

All monetary amounts are integers in the currency’s minor units (for USD, cents, so 9999 means $99.99). Each resource carries its own currency (ISO 4217), which may be null when not yet known.

​
Event envelope

Every creator.* webhook is delivered as an HTTP POST with this envelope:
  • id: the event id, stable across delivery retries. Also delivered as the Standard-Webhooks webhook-id. Unique per event on every creator.* topic except creator.message.read, see Delivery, Retries and Idempotency before using it as an idempotency key.
  • type: the event name (one of the topics in Available events).
  • timestamp: ISO 8601 time the event was emitted.
  • data: the resource object. data.object tells you the resource type (payment, subscription, follow, message, fan_message_read, post, reaction, refund, dispute, fan_status).
Fields inside data are snake_case.
This is the same Standard-Webhooks envelope the checkout events use. The legacy flat platform events keep their original flat, camelCase payloads.

​
Attribution

Two attribution fields travel with the resources that can carry them, but they are not populated uniformly across the domain:
  • client_reference_id (string | null) carries a real value only on the subscription events. It is present but always null on creator.payment.succeeded, and absent from every other resource.
  • metadata ({} when none was set) carries a real value on the subscription, refund, and dispute events. It is always {} on payment, follow, post, reaction, reward, message, and fan-status events.
Do not key reconciliation on these fields outside the subscription and refund/dispute events. See each reference page for the per-resource behaviour. Where metadata is carried, it is echoed from the original sale, so churn, refund and dispute events arrive with the attribution the purchase was made under. See Checkout Attribution for how these are set.

​
Available events

Each group links to a reference page with full field definitions and example payloads. The scope column is the OAuth scope your app must hold for the event to be delivered.
The two creator.experience_subscription.* events do not fan out to every consenting app. Holding read:experience for the creator is necessary but not sufficient: they reach only the app that owns the experience, plus the creator’s subscribed connector destinations. See Experience subscriptions.

​
Migrating from the legacy events

The legacy flat events map onto creator.* as follows. The creator.* payloads are richer (full money breakdown, billing reason, attribution) and share one envelope shape, so a single handler can process the whole domain.
During the migration window both the legacy event and its creator.* replacement fire. Subscribe to one or the other for a given concern to avoid double-processing.