Skip to main content
creator.* webhooks notify your backend in real time about activity across a creator’s Fanvue account: on-platform payments, subscriptions, direct messages, post and message engagement, refunds, and disputes. 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, etc.). 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": "f1a2b3c4-1111-4a2b-9c3d-aaaaaaaaaaaa",
  "type": "creator.payment.succeeded",
  "timestamp": "2026-06-09T08:39:33.139Z",
  "data": { "object": "payment", "...": "resource fields" }
}
  • id: unique event id, stable across delivery retries (use it to dedupe). Also delivered as the Standard-Webhooks webhook-id.
  • 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

Payment, subscription, follow, and refund/dispute resources echo two attribution fields when they were captured on the originating purchase:
  • client_reference_id: your passthrough reference (string | null).
  • metadata: your passthrough key/value map ({} when none was set).
This lets churn, refund, and dispute events carry the same attribution as the original sale. 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.
Event (type)data.objectScopeReference
creator.payment.succeededpaymentread:creatorPayments
creator.subscription.activatedsubscriptionread:creatorSubscriptions
creator.subscription.deactivatedsubscriptionread:creatorSubscriptions
creator.subscription.cancel_at_period_end_changedsubscriptionread:creatorSubscriptions
creator.message.receivedmessageread:chatMessages
creator.message.sentmessageread:chatMessages
creator.message.readfan_message_readread:chatMessages
creator.message.deletedmessageread:chatMessages
creator.message.reactionreactionread:chatMessages
creator.follow.createdfollowread:creatorEngagement
creator.post.likedpostread:postEngagement
creator.post.commentedpostread:postEngagement
creator.refund.createdrefundread:creatorRefunds and disputes
creator.dispute.flaggeddisputeread:creatorRefunds and disputes
creator.dispute.createddisputeread:creatorRefunds and disputes
creator.fan.status_changedfan_statusread:chatFan status

​
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.
Legacy eventReplacementNotes
follow.newcreator.follow.created—
purchase.newcreator.payment.succeededsource is post, message, or media
tip.newcreator.payment.succeededsource is tip
subscription.newcreator.subscription.activated—
subscription.cancelledcreator.subscription.cancel_at_period_end_changedAuto-renew turned off; access continues to expires_at
subscription.expiredcreator.subscription.deactivatedAccess removed; see deactivation_reason
message.receivedcreator.message.received—
message.sentcreator.message.sent—
message.readcreator.message.read—
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.