Listening to updates using webhooks
Requires Business or Enterprise, and included in the free trial. See Plans, access and limits.
A great way of building data-driven apps using Felt is by triggering a workflow whenever something changes on a map, like someone drawing a polygon around an area of interest or updating the details on a pin.
Instead of polling by listing annotations, comments or data layers on a fixed interval, set up a webhook and Felt will send your endpoint a notification any time a map is updated. This allows you to build integrations on top, such as sending a Slack message or recalculating statistics for a newly-drawn area.
How webhooks work
Each webhook is attached to a single map. When someone changes the map in the Felt app (drawing or editing annotations, editing layers or features, changing settings or sharing) or adds a comment or reply, Felt sends a POST request with a JSON body to your webhook URL:
{
"attributes": {
"type": "map:update",
"map_id": "Jzjr8gMKSrCOxZ1OSMT49CB",
"updated_at": "2024-04-29T12:16:46"
}
}A few things to know about the delivery model:
Event types.
map:updateis currently the only event type. The payload tells you which map changed and when, but not what changed — use the annotations, layers, or comments endpoints to fetch the current state when you receive an event.Deliveries are coalesced. A rapid burst of edits to the same map may result in a single notification rather than one per edit. Treat each delivery as "this map changed, re-read it", not as a per-edit event stream.
What doesn't trigger a webhook. Changes made through the REST API or the MCP server, resolving, editing or deleting comments, layers finishing processing, and scheduled refreshes don't currently send a notification. If your integration makes changes through the API, it already knows about them.
Retries. If your endpoint does not respond with a 2xx status, Felt makes up to 10 delivery attempts in total, with exponential backoff. This means delivery is at least once: your handler should be idempotent. Redirects are not followed.
Creation is UI-only. Webhooks are created in workspace settings (see below); there are no REST endpoints for managing them.
Verifying webhook signatures
Every webhook has a signing key, shown in the workspace settings UI when you create it. Felt signs each delivery with a felt-signature HTTP header containing the Base64-encoded HMAC-SHA256 of the raw JSON body, computed with that signing key. Use the key exactly as shown, as a string; don't base64-decode it first.
Verify the signature before acting on a payload — it proves the request came from Felt and not from a third party who discovered your URL:
Compute the HMAC over the raw request body exactly as received — re-serializing the parsed JSON can change key order or whitespace and produce a different signature.
Requirements
Two things are needed in order to make use of webhooks:
A Felt map which will serve as the basis for the webhook. Updates will be sent whenever something on this map changes.
A webhook URL where the updates will be sent in the form of
POSTrequests.
Generating a new webhook
Workspace admins and editors can set up webhooks in the Developers tab of the Workspace Settings page.
Simply click on Create a new webhook, select a map to listen to changes and paste in a webhook URL where the updates will be sent to.

Using your new webhook
In order to use webhooks effectively, a receiving service must be set up to trigger actions based on the updates sent by the Felt API. Here are some examples of how to set up a webhook using Felt and an external service.
Last updated
Was this helpful?