Webhooks

Webhooks notify your own service when something happens in Cevoid, such as a post being approved or a review being submitted. Your service receives a signed POST with the post, review or profile the event concerns, so you can act on it without polling the API.

Every request is signed, so you can verify it came from Cevoid. Requests are fixed POST calls with a JSON body; custom methods, custom authorization headers and inbound webhooks are not supported.

A destination is your HTTPS endpoint in Cevoid, with its own signing secret. Events reach it in two ways:

• Subscribe to events. Pick the events the destination receives, such as post.approved or product-review.submitted, or choose All events to receive every event, including event types added later. Each event is sent as it happens.
• Send from a Flow. For more control, build a Flow that sends to the destination: filter on the event, wait before sending, or send the review and upload requests that only Flows create, such as product-review-request.created.

Events from a Flow carry origin, which names the Flow and its trigger, so you can tell Flows apart when they share a destination. Subscribed events have no origin.

Common uses, each with the event to start from:

• Reward creators once their content is cleared for use: post.approved.
• Copy new product reviews into a CRM or a support tool: product-review.submitted.
• Route company reviews to the team that owns service quality: company-review.submitted.

The Event types page lists every event, the body they share and how payloads change over time.

1. Step 1

   Build a receiver

   Add an HTTPS route that accepts POST requests, keeps the raw request body and returns a 2xx status within 10 seconds. See Set up a webhook.

2. Step 2

   Create a destination

   In Settings → Developers → Webhooks, choose Create destination, enter your URL and pick the events it receives. Copy the signing secret. See Set up a webhook.

3. Step 3

   Verify every request

   Check the signature against the raw body before you parse it. See Verify webhook signatures.

4. Step 4

   Test it

   Send a test of each event you picked to receive a real signed request. See Test a webhook.

Every delivery is an HTTPS POST with these headers:

• Timeout: Cevoid waits 10 seconds for your response, body included. A slower response counts as a timeout and is retried.
• Body: at most 256 KiB (262,144 bytes) of JSON, with object keys sorted. A body that would be larger is never sent.
• Redirects: not followed. A 3xx response stops the delivery.
• Envelope: every event has the same top-level fields: type, id, created_at, version, origin and data. See Event types.

• At least once. Cevoid retries until your endpoint returns a 2xx status, so a response lost on the way back leads to a second request with the same webhook-id. Store the IDs you have processed and skip repeats.
• No ordering guarantee. Deliveries are sent and retried independently. Order your own state by created_at or by the timestamps of the resource in data, not by arrival.
• A snapshot of the first attempt. Cevoid reads the order, profile or review when it makes the first attempt and sends that same body on every retry. Fetch the resource from the API when you need its state right now.
• Retries for about 20 hours. A failed delivery is retried up to six times. See Retries and replays.

• Set up a webhook: create a destination and pick its events, or send to it from a Flow.
• Verify webhook signatures: check that each request came from Cevoid before you parse it.
• Retries and replays: respond, deduplicate and recover failed deliveries.
• Test a webhook: send a signed test event and read the delivery log.
• Event types: the envelope and every event.