monday.com and Make, connected without a runaway credits bill
How to wire monday.com to Make so a board change reaches the rest of your stack once, in the right shape, at a predictable cost in Make credits (the unit that replaced operations), and where a scenario is the wrong tool for the job.
monday.com owns the state of a piece of work. Make moves data between that state and everything else. The pairing works because each is good at what the other is poor at: monday's own automations are legible but stop at the edge of the board, and Make will reach almost any API but has no idea what a board means.
Three decisions decide whether the connection holds up. How Make hears about a change, which is push or poll. How it writes back, because column values are typed JSON rather than strings. And how it knows which item it is talking about, which is by ID and never by name. Most scenarios that misbehave got one of the three wrong in the first hour.
A board change, end to end
The shape is the same whichever direction the work goes. What differs is where the cost and the failures sit.
- 01
A column changes on the board
monday emits an event: item created, a column value changed, an update posted. Make receives it either by an instant webhook trigger or by polling on a schedule. The two are different modules and behave differently, covered below.
- 02
The event is thinner than the row
A column-change event typically carries the item ID, the board ID, the column that changed and its new value. It does not carry the other columns. A scenario that needs the customer name and the due date has to fetch the item, which is one more credit on every event, and it belongs in the estimate.
- 03
Filter before doing anything expensive
Test the column and the value that matter, directly after the trigger. A board where people edit ten columns per item sends ten events per item, and nine of them should stop at the filter rather than reach a module that costs money or calls an API.
- 04
Act on the other system
Create the invoice, post the message, call the API. Anything with a side effect gets a stable key from the item ID, so the same event arriving twice leaves the same result.
- 05
Write back by item ID, in the column's own shape
The write-back is an update against the item ID with a value built for the column type. It can also fire monday's own automations and, if the scenario watches that column, the scenario itself. A write-back without a guard against its own echo is how loops start.
Three ways Make can hear about a change
This is the choice that sets both the latency and most of the credits bill. Make now bills in credits, which replaced operations in 2025, and for most modules one module run is one credit.
Instant webhook trigger
Where the module you pick is an instant trigger, Make registers a webhook on the board and monday calls it when the event happens. Latency is short, and an idle board costs nothing. The scenario has to be switched on for events to be processed, and the trigger fires for every event of the type you chose on that board, so the filter right after it does the real work. If you ever register a webhook against monday by hand rather than through the module, note that monday verifies the URL when it is created and expects the challenge echoed back.
Choose it whenA status change or new item must be acted on promptly and the board is not extremely noisy.
Scheduled polling
Make asks monday on a schedule whether anything is new. Every scheduled run costs at least one credit even when the answer is no, so a fifteen-minute interval spends about 2,900 credits a month (96 runs a day over 30 days) before it has done any work. Check in the module list whether the watch module you want is instant or scheduled, and which event it watches: items created and column values changed are different modules, and picking the wrong one is the most common reason a scenario never fires.
Choose it whenChanges arrive a few times a day, a delay of minutes is fine, and the integration must not depend on a registered webhook staying alive.
monday calls Make only for the items that matter
A monday automation or its webhook integration, where the plan includes it, posts to a Make custom webhook only when a specific status is set. The board makes the decision, so Make is woken only for matching items and the credits follow the real volume of qualifying events rather than the volume of edits. monday limits automation and integration actions by plan, so check the allowance too.
Choose it whenThe board is noisy, the qualifying event is easy to state in a monday recipe, and credits are the constraint.
Writing back: the shape depends on the column
A status is not written like a date, and neither is written like a person. Get the shape wrong and the call is rejected or, worse, accepted and ignored.
| Column type | What the API expects | What goes wrong |
|---|---|---|
| Status | A label or an index. | An unknown label is rejected unless label creation is explicitly allowed. Renaming a label on the board silently breaks any scenario that writes the old text. |
| Date | A date string, plus a time where one is set; the time is UTC. | A time written as local time and read as UTC lands hours out, and nothing errors. Confirm which one each side assumes before the first real item. |
| People | User or team IDs. | The API takes IDs, not names or email addresses, so the scenario needs a lookup from email to user ID, kept in one place and not rebuilt in every module. |
| Connect boards | The item IDs of the linked items. | You need the target item's ID, which means searching or storing it first. Linking by name is not possible. |
| Mirror and formula | Nothing: they are read-only. | A write fails. The fix is to write to the source column the mirror reads from. |
| Subitems | The subitem board's own IDs. | On classic boards, subitems live on a separate, hidden board, so a trigger or create-item module pointed at the parent board never sees them. Multi-level boards keep subitems on the same board; check which kind you have. |
What goes wrong with monday.com + Make
The patterns that turn up on this pair specifically, and what we do about each one.
- 01
Credits spent fetching what the event did not carry
Trigger, fetch item, then the work: three credits before anything has happened, multiplied by every edit on the board. The fixes are narrowing the trigger to the column that matters, filtering immediately after it, and where a scenario would otherwise fetch items one at a time in a loop, making one GraphQL call through the generic API-call module that returns the whole batch with only the columns required.
- 02
The complexity budget, hit by a loop
monday's API is GraphQL with a complexity budget per minute rather than a flat request count, so a query asking for many columns on many items costs far more than a small one. A scenario that fetches an item per bundle across a large board can exhaust it and start receiving errors. Page with a cursor, ask for the columns you will use, and put a Break handler with a retry interval on the module, with incomplete executions allowed in the scenario settings, so a rate-limit response waits and retries instead of dropping the bundle.
- 03
Duplicate items from a retried write
A source that re-sends, or an incomplete execution replayed after a partial failure, runs a plain create-item twice. Keep the source system's ID in a dedicated text column, search by it before creating, and update when it exists. Do not count on the board to reject a duplicate: the check lives in the scenario, and it has to run on every create path, not only the main one.
- 04
Loops between a scenario and a recipe
The scenario sets a status, a monday recipe reacts by changing another column, and the scenario's trigger sees that change. Each pass costs credits and may re-run side effects. Guard it by filtering on the specific column and value, by writing only when the value actually differs, and by listing every recipe on the board when a loop appears, because the cause is usually one nobody remembers writing.
- 05
IDs that do not survive a copy
Column IDs, group IDs and user IDs belong to the board and the account. Duplicating a board, rebuilding a column or moving to another workspace can change them, and the scenario carries on, writing to a column that no longer exists or to the wrong one. Put every ID in one mapping at the top of the scenario or in a data store, and verify them after any restructure of the board.
- 06
A personal token that reaches everything
A Make connection to monday acts with the permissions of whoever authorised it, which on a live account can include commission and cost columns. Authorise the connection from a dedicated integration user whose board access is the boundary, so the scenario can only see what it needs. This may use a seat, and it is worth it.
A quote is accepted and a delivery item appears, once
The set-up
Illustrative, not a client result. A quoting tool posts a webhook when a customer accepts. The delivery team works from a monday board, and the quoting tool should hold a link back to the item.
What it comes to
About six module runs per accepted quote (the router itself uses no credit), so if 200 quotes were accepted in a month that is on the order of 1,200 credits. That figure is the same whether the board holds fifty items or five thousand, because nothing in the scenario iterates the board.
- 01
Custom webhook receives the acceptance
Make's webhook module takes the quote ID, customer, value, requested date and owner email.
- 02
Search the board by the quote ID column
One call finds an existing item with that quote ID in the source-ID text column. A resent webhook now finds its own earlier work.
- 03
Router: exists or new
The existing route updates the date and value. The new route creates the item with the status label, the date and the person ID, resolved from the owner's email through a lookup kept in a data store.
- 04
Write the item ID back
The item's ID, or its URL built from the board and item IDs, is written to the quote record so each system points at the other.
When a scenario is the wrong tool
Keep it inside monday when the rule lives entirely on the board. A native automation that sets a status when a date passes uses no Make credits (it counts against monday's own automation allowance) and leaves one place to look when it misbehaves. Reach for Make when the rule needs another system, a lookup monday does not hold, or arithmetic the recipe library cannot express.
Put a small server in front of the board when the logic needs state across events. Business-day SLA clocks, escalation that must survive a reallocation, matching an inbound document against existing items, or any aggregation across items are all awkward as scenarios, because a scenario sees one event at a time. The fleet-telematics build used for adjacent reading below does exactly this: one service owns the monday token and every board write, and the front end never touches it.
And do not use a scenario as a portal. If contractors or clients need to update items without a seat, they need a page that shows only their own work and writes back server-side, which is a different build from a trigger and an action.
Projects that did not use monday.com + Make
Here for the argument rather than as evidence of this integration. Each one bears on a point above, and the note says which.
- A fleet-telematics providerOrders that file themselves, and an SLA clock that never forgetsNot a Make build. It reaches monday.com through a Python service instead of a scenario, because the work needed state, a business-day clock and a credential kept in a single process. It is here for the matching rule: an inbound order is matched to an existing row so a resend updates it rather than creating a second one, which is the duplicate-item guard above.Case study
- FormCraftFormCraft: a form platform with an API automation can callNot a monday.com build. It is the Make side of the trigger choice: an outbound webhook on insert so Make is woken instantly, with polling kept as the fallback. The same push-versus-poll decision drives the cost of the monday scenario above.Case study
The disciplines behind it
Related reading
Rate limits, plan tiers and which modules exist change over time. Where this page gives a figure it shows how it was derived; for everything else, confirm against the vendors’ current documentation before sizing a build. Skofi holds no partnership, certification or reseller arrangement with any vendor named here.
monday.com + Make, specifically
Yes. Make ships a monday.com app with dedicated modules, including watchers for new items and changed column values, plus a generic Make an API Call module for anything the dedicated modules do not expose. We are not affiliated with either vendor. The practical test is not whether the app exists but whether the specific operation you need is a module, so check the module list for your use case before planning around it.
Three causes cover most of it. The scenario is switched off, so it is not processing events. The trigger watches item creation, not column changes, because they are separate modules. Or the item is a subitem on a classic board, which lives on a hidden board the trigger was never pointed at. Check those in that order before rebuilding anything.
Make bills in credits, which replaced operations in 2025, and for most modules one module run is one credit. Count module runs per event, not modules: the trigger, a fetch if you need the full row, any search, then each action. With a filter straight after the trigger, noisy boards stop costing money for edits that do not matter. A polling trigger adds a fixed cost on top, because each empty check still counts. We estimate from the real event volume before building and compare it with the first week of run history.
No. Both are computed from other columns and are read-only through the API. If a value appears to need writing, write it to the column the mirror or formula reads from, or reconsider whether the number belongs on the board at all.
Use monday's own automations for anything that stays on the board, and Make for anything that crosses to another system or needs logic the recipes lack. Mixing them freely is fine; what causes pain is two things changing the same column. Decide which one owns each column and document it.
Yes, by authorising the connection as a dedicated integration user and giving that user access only to the boards the scenarios need. A connection acts with whatever the authorising user can see, so using a personal login is what exposes everything. It is a small change that removes a large risk.
Sources
Statements about what a platform, regulator or provider says come from their own pages. Rules and limits change, so check the current page before you rely on one.
- Webhooks · monday.com (API reference)
- Rate limits · monday.com (API reference)
- Column Types · monday.com (API reference)
- Working with multi-level boards · monday.com (API reference)
- Credits · Make (Help Center)
- Overview of error handling · Make (Help Center)
Page copy drafted with AI assistance. Skofi is accountable for it. Editorial policy
Tell us about the process that keeps costing you.
A 15-minute call is usually enough to say whether this is an automation, an integration, or something that should be built, and whether we are the right people for it.
What happens on the call
- 15 minutes, no deck
- We map the process on the call
- A written scope, or an honest no