Skip to main content
Webhooks push events to your server as they happen, so you don’t have to poll. They cover the two moments that are asynchronous by design — publish approval and creator activity — plus everything downstream. Configure your webhook URL in dashboard settings. One URL per account receives all events.

Events

Decision events (creator.*, submission.*) fire regardless of where the decision was made — so an integration stays in sync even when your team works in the dashboard.

Payloads

Every event is a JSON POST with the event type, campaign context, the affected resource, and a timestamp:
campaign.status_changed carries previous_status, status, and status_detail instead of a resource object. creator.* events carry a creator object; post.* events carry a post object — the same shapes the read endpoints return.

Verifying signatures

Each delivery is signed with HMAC-SHA256 using your webhook secret (shown alongside the URL in dashboard settings). The X-Launchpoint-Signature header contains the hex digest of the raw request body:
Always verify before trusting a payload, and compute the HMAC over the raw bytes — not the re-serialized JSON.

Delivery and retries

  • Respond with any 2xx status within 10 seconds to acknowledge receipt.
  • Failed deliveries are retried with exponential backoff for up to 24 hours.
  • Delivery is at least once: build your handler to be idempotent (the combination of event_type, resource id, and timestamp makes a good deduplication key).
  • Events may occasionally arrive out of order — trust the resource’s status, not the arrival sequence.