Webhooks

A webhook sends a signed message to an address on your server when something public happens on a product. For example, a new idea arrives or a status changes. Use it to update your own systems. The full reference is on the developers page.

Who can use it

Every plan includes webhooks. Only workspace owners and admins can add, pause, rotate or delete them. Other people see a note that says who can manage them.

Add a webhook

1. Select Product settings under your product in the left menu.
2. In the Connect list, select Webhooks.
3. Under Add a webhook, enter your server's address in Endpoint URL.
4. Under Events, tick each event you want to receive, such as New post.
5. Select Create webhook.
6. Select Copy to copy the signing secret.
7. Save the signing secret in your server's secret store. It is shown only once.

Endpoint rules

The endpoint must be an https:// address that accepts POST requests. It must use port 443 (the default) or 8443, and it must be a public address. It cannot contain a user name, a password or a # part.

A product can have up to 10 webhooks. Clear Active to pause one. A paused webhook keeps its settings and receives nothing.

Events

Ideas that were imported, posted through the API or posted by your team on someone's behalf do not send New post.

The form also has a Waitlists group and a Surveys group. Their events are off until you tick them, because they are about people.

• Someone joined a waitlist, Someone left a waitlist and Someone was invited from a waitlist send the waitlist, the place and your own user id for the person. They send names, email addresses and answers only when you tick Include people's names, email addresses and answers in waitlist events. Only tick that for an endpoint you control.
• Someone completed a survey sends the survey answers and score, with your own user id where the person came from your app. It never sends an email address.

What is sent

A webhook sends only what your public portal shows. Nothing is sent while the portal is private, for a private board, for an idea that is pending or hidden, or for a move into a status the board hides. Waitlist events are the exception, because they are about the people on your own waitlists.

Each delivery is a POST with a JSON body like this. The values are samples:

{
  "id": "evt_sample_8f3a",
  "type": "post.status_changed",
  "occurredAt": "2026-10-15T09:30:00.000Z",
  "product": { "publicKey": "pk_sample" },
  "data": { "title": "Dark mode for the dashboard", "voteCount": 128 }
}

The data part holds the idea, comment or release, in the same form the public read API uses. In an idea, voteCount is a number, or null when the board hides its vote totals.

The event names are post.created, post.status_changed, comment.created, changelog.published, waitlist.joined, waitlist.left, waitlist.invited and survey.response_completed.

Check the signature

Every request has three headers:

To verify a delivery:

1. Use the raw body exactly as it arrived, before any JSON parsing.
2. Compute the HMAC-SHA256, in hex, of the timestamp, a dot and the raw body, using your signing secret.
3. Split the x-fh-signature header on commas, and ignore any value that does not start with v1=.
4. Accept the request if any value matches yours, compared in constant time. Never compare the whole header.
5. Refuse a request whose timestamp is more than 5 minutes from your own clock.
6. Skip any delivery whose body id you have already handled.
7. Refuse a delivery whose x-fh-event-id header differs from the body's id.

Answer with any 2xx status to acknowledge a delivery. A redirect is never followed.

Retries and the delivery log

If your server does not answer with a 2xx status, IvaBoard retries up to five more times. Each wait is at least 30 seconds, then at least 60, 120, 240 and 480 seconds, and can run up to twice as long. After the last retry fails, a background job marks the delivery Abandoned, and it is not sent again. The Next attempt column in the log shows the earliest time of the next try.

To see deliveries, select Manage on the webhook. Its Delivery log lists each event, its state, its attempts and its last response. The states are Queued, Delivered, Failed, will retry and Abandoned. The log keeps 90 days. A daily clean-up removes older entries, so an entry can stay up to a day longer.

Rotate the secret

Rotating gives you a new signing secret. For 24 hours each delivery is signed with both the new secret and the old one, so your endpoint keeps working while you switch over. Your check must accept either value, as described above.

1. Select Rotate secret on the webhook's row.
2. Select Rotate this secret.
3. Select Copy to copy the new signing secret.
4. Save the new secret in your server's secret store.
5. Deploy the new secret on your server within 24 hours.

If a secret may have leaked, delete the webhook and create it again instead. Rotating would keep the old secret working for 24 hours.

Delete a webhook

Deleting a webhook also deletes its delivery log, and the endpoint stops receiving events at once.

1. Select Delete webhook on the webhook's row.
2. Select Delete this webhook.

Example

For example, Sam at Acme Notes adds https://hooks.example.com/ivaboard as an endpoint. He ticks New post and Status change, then selects Create webhook. He copies the signing secret and saves it in his server's secret store.

What to read next

• API keys and the IvaBoard API
• Slack and Microsoft Teams notifications
• Publish a changelog update