Creator events overview

creator.* webhooks report activity across a creator’s Fanvue account as it happens: on-platform payments, profile subscriptions, fan-experience subscriptions, messages, chat inbox state, engagement, refunds, disputes, and fan mute and presence changes. Checkout-link sales have their own family, starting at Checkout link payment events. You need a destination for each topic, registered as described in Subscribe to webhooks, the scope in the table below on the creator’s consent, and a receiver that verifies X-Fanvue-Signature on every delivery. If you’re moving off the legacy events, start at Migrating from the legacy events.

​

Available events

Each row links to the reference page with the event’s fields and example payloads. The Scope column is the OAuth scope your app must hold for the event to be delivered; Scopes explains how to request it. creator.payment.pending and creator.payment.failed are reserved names. No code path emits them, and they cannot be subscribed to.

​

Event envelope

Every creator.* event arrives in the shared envelope. Two points apply to this family:

• id is stable across delivery retries and unique per event occurrence on every creator.* topic, so it serves as an idempotency key. See Deduplicating events.
• timestamp is stamped when the delivery is built, so it moves on a retry. Order on the time fields inside data (read_at, marked_at, changed_at, paid_at) instead.

data.object names the resource type: payment, reward, subscription, experience_subscription, message, mass_message, fan_message_read, creator_message_read, chat_unread_marker, follow, post, reaction, refund, dispute or fan_status.

​

Amounts and currency

Amounts are integers in minor units (USD cents, so 9999 means $99.99), and each resource carries its own ISO 4217 currency, which is null when not known; Units and currency covers fees and settlement.

​

Delivery

A creator.* event goes to every app whose consent for that creator covers the event’s scope and that has a webhook endpoint subscribed to the topic, plus the creator’s own connector destinations. There is one exception. creator.experience_subscription.* events reach only the app that owns the experience and the creator’s connector destinations, however many scopes another app holds. See Experience subscriptions.

​

Attribution

Two attribution fields travel with the resources that can carry them, and they are not populated uniformly across the family:

• client_reference_id (string | null) carries a real value only on the subscription events. The key 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. The value is always {} on payment, reward, follow, post, reaction, message, chat and fan-status events.

Key reconciliation on these fields only for the subscription, refund and dispute events. Where metadata is carried, it is echoed from the original sale, so a churn, refund or dispute event arrives with the attribution the purchase was made under. Checkout attribution describes how the values are set.

​

Migrating from the legacy events

creator.* events replace the legacy flat platform events (New Follower, Purchase Received, Message Received and the others). The legacy events are deprecated but keep firing, so existing integrations keep working, and new integrations subscribe to creator.*. The creator.* payloads carry the full money breakdown, billing reason and attribution, and share one envelope, so a single handler can process the whole family. The legacy events map onto them as follows. There is no legacy message.sent event. creator.message.sent is the only event for a creator’s outbound message.