Guide

How to schedule recurring imports into monday.com

Getting data into monday.com once is easy. Getting the same data in again next Monday, updated rather than duplicated, is the part that needs a decision.

Last checked : the schedule shapes, the source rule and the measured rates below, against the code and the runs that produced them.

The answer in short

monday.com does not schedule imports for you: its built-in import runs when you start it, and its bulk API is a job you call. So a recurring import is something you build, or something you buy. Whichever you choose, it has to read from a source that can be fetched again — a URL, a sheet or a connected app — because a file somebody uploaded once cannot be.

Start with what monday.com already gives you

monday.com has a built-in import you can start from a board. It runs when you start it, and you repeat the mapping each time — which is fine for a one-off migration and tiring for a weekly refresh.

For anything programmatic, the platform API does the heavy lifting. As of API version 2026-07, ingest_items takes a CSV upload of up to 10,000 rows (150 MB) per job, and can update the rows it matches via on_match rather than creating duplicates. backfill_items takes up to 20,000 rows for a one-time initial load. Both are asynchronous jobs: start the job, upload the file, poll for status.

That is a solid import path. It is also still a set of calls you have to make, on a timetable you have to run yourself.

Verified 2026-09-11: the bulk-import endpoints, their row and file limits, the on_match update behaviour and the per-account budgets described above come from monday’s own API documentation, developer.monday.com/api-reference/docs/importing-items-in-bulk . monday.com changes limits between API versions, so re-check that page before you rely on a number.

The five routes, compared on the things that decide it

Effort, cost model and error visibility for each way of repeating an import.
Route Recurring Ongoing effort Cost model Error visibility
monday.com’s built-in import No — you start each one Minimal Included in your monday.com plan A summary when the import finishes
A per-task automation tool Yes Low, until the data gets large Billed per task or per run Task run history, not per row
The monday.com platform API plus your own scheduler Yes High — you build and operate it Your infrastructure and someone’s time Whatever you build yourself
An import app from the monday marketplace Yes Low A subscription, often with import quotas Varies by app — check before you buy
Boardfeed Yes, for a source it can fetch itself Low — mapping and a schedule $0, $19 or $49 a month; rows written are metered per month A row-by-row check over a sample before the run, an error CSV by e-mail after it

Pricing and error handling vary a lot between marketplace apps. One of the better-known ones is compared here, with the public source for every figure quoted.

What a scheduled import has to get right

Whichever route you take, these are the parts that separate a scheduled import you can forget about from one you end up checking every week.

  • A source that can be read again. This is the first question, not a detail. A schedule needs something the importer can fetch on its own — a URL, a sheet, a connected app. A file you uploaded is not that: it cannot be read a second time, so a schedule on it is a job that quietly stops working. Boardfeed refuses to save one rather than let it fail in week two.
  • A key that identifies a row. Without one, every run adds a second copy of everything. Pick the column that is unique and stable — an order id, a customer id, an email — and import the source’s own id whenever it publishes one. A scheduled import in Boardfeed has to have a match column, or an explicit confirmation that every run is meant to add new rows.
  • A mapping that survives renames. Source systems rename columns. Mapping by header name rather than by position is what stops a rename from shifting every value one column to the left. Ask the harder question too: when a mapped column stops arriving, does the run tell you, or does it succeed quietly with that field empty? In Boardfeed, marking the column required is what turns that silence into a reported row.
  • Retries with backoff. Both ends have rate limits: the API you read from, and monday.com’s own request and complexity budgets. A run that fails on a limit has to wait and try again, not give up until next week.
  • Overlap protection. A large import can outlast its own interval. The scheduler must refuse to start a second run while the first is still going, or the two will fight over the same items.
  • Per-row errors, not just a pass or fail. The useful output is the list of rows that failed and the reason for each: an unknown status label, a date the board cannot parse, an email column that needs both an address and a display name. Without it, a run that reports “1,480 of 1,500 rows imported” is where the work starts.
  • A history you can look back at. When someone asks why a board changed on Tuesday, the answer has to be a run record with counts, and the error file from that run.
  • Credentials you can rotate. Keys expire and people leave. A token that can be replaced in one place, without rebuilding every import, is the difference between a five-minute job and an afternoon.

Pick an interval the run can finish in

An hourly schedule is a promise that the run ends inside the hour, and how long a run takes is decided by monday.com, not by the importer. These are Boardfeed’s own measured numbers, each with the run that produced it — they are not a sustained rate, and the row-by-row figure is the one to plan against when a mapping cannot use monday’s bulk endpoint.

Measured import rates, with the conditions of each run.
Rate What was run Where and when
48.7 items/s One 10,000-row bulk job, 10,000 created, 0 failed, 205.5 s end to end. A real monday sandbox board, 2026-09-12.
31.4 items/s Bulk upsert — 1,000 items updated at the worker’s defaults (10 per request, concurrency 2). Sandbox board, 2026-09-12.
26.1 items/s One realistic mapping — name, text, status, date and number — over 1,000 rows, 2 % of them carrying a status label the board does not have: 980 created, 20 failed. Sandbox board, 2026-09-12.
3.2 items/s The same 1,000 rows and the same 980 / 20 result on the row-by-row path, which is what a run falls back to when its columns cannot go through the bulk endpoint. The same run, 2026-09-12.

The gap between the two paths is the thing to plan around. monday’s own complexity budget bounds the row-by-row path at about 5.5 items/s sustained, however the requests are batched. A 50,000-row daily sync that lands on that path therefore takes hours, not minutes. Size the interval for the slow path, not the fast one.

Test it before you trust it

  1. Run the import manually first and read the check, not the result.
  2. Run it a second time without changing the source. If the board grows, the key is wrong.
  3. Change one field upstream and confirm the item is updated in place.
  4. Add a deliberately broken row and confirm it fails alone, with a reason, while the rest imports.
  5. Leave it for two cycles and check the run history rather than the board.

Where Boardfeed fits

Boardfeed is the packaged version of this. You map a source to a board once, choose a key column and a schedule, and the run history keeps the counts for every run.

  • Schedules: manual, hourly (UTC), daily, weekly, or a cron expression, the last three in a time zone you pick.
  • Before the first run: a check reads a sample of the source — 20,000 rows by default — through the import engine’s own rules and lists each row it would refuse, with the row number and the reason. It tells you how many rows it read rather than implying it read them all.
  • After a run: the rows that were left out arrive as a CSV attached to the e-mail, and the run history offers to re-import just those rows.

The sources it can fetch on a schedule are Google Sheets, any REST or JSON endpoint, and key-based connectors for Mailchimp, Stripe, Airtable, HubSpot, Notion, Klaviyo and Shopify. CSV and Excel uploads work the same way in every other respect but run when you start them: an uploaded file cannot be read again later, so Boardfeed will not save a schedule on one.

Pricing is flat — $0, $19 or $49 a month — with one metered dimension: the rows a run writes to a board, counted per calendar month. Rows that are skipped, that fail, or that a run never gets to are not counted. Imports, boards and scheduled runs are not capped, and no source or schedule shape is reserved for a paid plan.

If you would rather see it per source, the how-to pages start at importing a CSV into monday.com: 20 source guides cover files, sheets and APIs, each with the field-mapping details that trip up a first attempt. If you are weighing Boardfeed against the best-known marketplace importer, the sourced comparison is the page for that.