monday.com webhooks created by an app: why you can't edit them, and how to fix one

It means the webhook was created through monday's API using a monday app's integration token rather than by someone on the board. monday's Webhooks reference says end users cannot disable webhooks created that way, so that the app is not disrupted by a curious user toggling it on and off. The lock is intentional, it is not a permissions error, and no board setting removes it.

So the fix has to happen where the webhook was made. If it belongs to a marketplace app or a tool you connected, remove or reconfigure it in that tool, or disconnect the app. If it belongs to an app you built, list the board's webhooks through the API with that app's token, delete the one you no longer want and create its replacement. Whichever route you take, find out which kind of webhook you have first, because the four kinds on a monday board are removed in four different ways.

A board can receive outbound webhooks in four ways, and from a distance they look alike. The difference is who created each one and with which credential, and that decides who is able to turn it off.

Two places in monday show what is connected. On a board, the Automations page has a Manage tab, and its My connections tab lists the apps and integrations used on that board. Account admins can see every app and automation connection in the account under Administration, then Connections, then Automation connections. monday's Help Center also notes that uninstalling an app removes it from the account but does not automatically delete automations that were set up with it; those have to be deleted by hand. It does not say whether webhooks an app created through the API go with the app, so after an uninstall, check the board rather than assume.

Because the app depends on them. An app that keeps a board in step with another system, or reacts to status changes, breaks quietly when its webhook goes, and the person who switched it off is rarely the person who finds out. monday's answer is to let only the app control its own subscriptions. We think that is the right default for a marketplace, and the trade-off is real.

The cost lands when the app's side is broken or abandoned. If the vendor's endpoint is down, or the app you built was retired without its webhooks being deleted, the board keeps sending events and nobody on the board can stop it. The person who can is whoever holds that app's credentials. For an app you built, that is an argument for keeping the app's OAuth token, or the ability to generate one, somewhere a successor can find it, along with a record of every webhook the app created.

monday's API has one webhook query and two webhook mutations: webhooks, create_webhook and delete_webhook. There is no update. Requests go to https://api.monday.com/v2 as a POST with the token in the Authorization header. Reading needs the webhooks:read scope and writing needs webhooks:write. The examples below are complete GraphQL documents to send as the query value; replace the board and webhook IDs with your own.

monday's reference describes app_webhooks_only as returning only the webhooks created by the app initiating the request, so run it with the app's token. The Webhook type has four fields, id, board_id, event and config, and nothing else. It does not return the target URL or say who created it, which is why two webhooks with the same event and config cannot be told apart from the API alone. Your own record of what you created is the only way to know which one is yours, and which is the one pointing at a server that no longer exists.

Create before you delete. Done the other way round, events in the gap are lost, and monday will not replay them. Done this way, there is a short window in which both webhooks fire for the same event, which is harmless if the receiver is idempotent and a duplicate if it is not. On create, config is a JSON string, and only three events take it: change_specific_column_value with a column ID, change_status_column_value with a column ID and the label index, and item_moved_to_specific_group with a group ID. The URL is limited to 255 characters. For subitem events, pass the parent board's ID, and add a query parameter to the URL if one endpoint needs to tell subitem events from item events.

If you are fixing a webhook created by someone else's app, you will not have its token, and monday's reference does not say whether a personal token can delete a webhook another app created. Try it on a test board before you rely on it. The dependable route is through the app: reconfigure or disconnect it, or ask its vendor.

For anything that must keep running, create webhooks with an app's integration token rather than a person's API token. monday's reference makes two features conditional on it: the lock that stops board users disabling the webhook, and a JWT in the Authorization header of each delivery that lets your endpoint prove the request came from monday.

On the receiving side, verify the JWT against the app's Signing Secret with a standard library, check that aud matches your endpoint URL and that exp has not passed, and reject anything that fails. A personal-token webhook carries no such proof, so its endpoint is an open URL that anyone who learns it can post to. If you must use one, treat the payload as a hint: re-read the item through the API before acting on it.

Mind the reach of a personal token in either case. On the fleet-telematics build in our work, the monday.com token was account-wide and reached commission columns, so it lives in one server-side process and nothing else ever sees it. The same applies to a token that creates webhooks, because it can usually also read every board the person can.

The challenge

When a webhook is created, by recipe or by create_webhook, monday sends a JSON POST to the URL containing a challenge field with a random token, and expects the same token back as a challenge field in the JSON response. If the endpoint does not echo it, the webhook is not created. That makes create_webhook a test of the endpoint as well as a registration: a URL that is down, behind authentication, or answering with a different body fails here. In our experience, the usual cause of a create that fails for no visible reason is an endpoint that returns 200 with an empty body or its own JSON instead of the echoed challenge.

Retries

monday's reference says requests sent through its webhook integration retry once a minute for 30 minutes. Plan around both halves of that sentence. Within the window, a slow or failing endpoint can receive the same event more than once, so the handler has to be safe to run twice. After the window, treat the event as lost: an outage of an hour on your side is an hour of board changes that will not arrive by webhook.

• Answer fast and do the work afterwards. Acknowledge the delivery, put the event on a queue or in a table, and process it from there, so a slow downstream API cannot turn into a failed delivery and a retry.
• Deduplicate on the event. Each payload carries a triggerUuid, along with the item (pulseId), the board, the column and changedAt. monday does not document whether a retry keeps the same triggerUuid, so use it as a first check and make the write itself idempotent anyway, with find-or-create on a stable key.
• Use previousValue. Column-change payloads carry the old value as well as the new one, so a handler can ignore an edit that did not change what it cares about without fetching the item.

Each tool does it differently, and the difference decides whether deleting the scenario or workflow also removes the webhook from the board. We are not affiliated with monday.com, Make, Zapier or n8n.

Make

Make's monday.com documentation describes instant modules as needing a webhook you set up in monday: create the webhook in Make, copy its address, then on the board add monday's Webhooks integration, pick a template and paste the address. The monday side is therefore an ordinary Webhooks recipe on the board, owned by whoever added it, and the Make connection itself uses a personal API token. Deleting the scenario does not touch that recipe. Make's help pages say a webhook not attached to any scenario for more than 120 hours is deactivated and answers 410 Gone, so the board goes on posting each event to an address that refuses it, and each failed delivery is retried for 30 minutes. The clean removal is both sides: delete the recipe on the board, then the scenario and its webhook in Make. Our monday.com and Make integration guide covers the trigger choice and the rest of the pairing.

Zapier

Zapier's app listing labels most of its monday.com triggers as instant. Zapier's platform documentation describes how instant (REST hook) triggers work: the integration subscribes when a Zap is turned on and unsubscribes when it is turned off. That makes turning off or deleting the Zap the clean way to remove its subscription. Zapier does not publish how its own monday.com app registers hooks on the board, so after turning a Zap off, list the board's webhooks and check that nothing is left behind.

n8n

n8n's built-in monday.com node is documented with board, column, group and item operations, with the HTTP Request node for anything else. To react to board events, the common pattern is a Webhook node whose production URL is registered on the board, by a Webhooks recipe or by create_webhook, and which returns the challenge so registration succeeds. monday.com also publishes its own n8n package with a trigger node. It is pre-1.0, and its README says to deactivate and reactivate the workflow after changing the webhook URL so the trigger re-registers. Whichever route you use, deactivating a workflow does not delete a recipe someone added by hand.

What monday.com webhooks cannot tell you

There are 21 event types, covering item and subitem creation, names, column values, moves, archiving, deletion and restoring, updates, and column creation. There is no event for a group being created or a column being deleted, and a webhook is attached to one board, so changes across boards need one webhook per board. When the event you need is not on the list, a sweep that reads the board on a schedule is the answer, not a cleverer webhook.

Not for anything that must not miss an event. A webhook is the fast path, and it is not a guarantee: deliveries stop after 30 minutes of failure, a recipe can be switched off, and nothing in monday's documentation promises the order in which a burst of edits arrives. Pair the webhook with a scheduled sweep that compares the two systems and fixes the difference, and make both write through the same idempotent path.

That is the shape of the role sync in our Make projects library, which copies job roles between two monday.com workspaces. Two instant scenarios carry the changes, and a third runs every fifteen minutes and looks for anything they missed, checking by name before it creates anything so the overlap cannot duplicate. Across the three scenarios Make has counted 292 runs and 622 operations, and the sweep has polled 265 times with no misses recorded. The sweep costs two operations when there is nothing to do, which is a small price for not having to trust the webhook.

Where it breaks: a sweep has its own limits. That one reads the forty newest roles, which suits its volume and would need widening if hundreds arrived inside one window, and it matches by name, so a renamed role is created again on the other side. A sweep also costs something on every run, which our Make.com credits article puts in numbers. And if the requirement is really a database with a board in front of it, our monday.com page explains when to move the logic off the board altogether.

A disclosure. Skofi is paid to build and repair integrations on monday.com, including the webhook handling described here. We are not a monday.com partner and hold no certification or reseller arrangement with monday.com, Make, Zapier or n8n.