These calls can start paid work, so they can spend from your wallet:

These do not start paid work by themselves: a dry run (estimate_trigger_cost), creating a blank or webhook table, inserting rows into a table with Auto-run off, and reading a trace. Stop and cancel prevent more spending. They do not give money back.

For prices in the app and where to add funds, see Your wallet and keeping spend under control.

Each template can carry a cost that says what one row costs from your wallet. Its kind is one of:

For AI templates and waterfalls the per-row figure is approximate. A waterfall also has maxUsd, the most one row can cost. A manual or api template has no cost key. A missing cost means a price does not apply. It does not mean the price is zero.

Two things to know about the estimate:

Important: without rowIds, a trigger runs every row in the table and spends accordingly. Always send rowIds, and price the run with a dry run first. Through MCP, call estimate_trigger_cost first, or pass specific rowIds.

This is the same habit as in the app. See Run columns safely: Auto-run, test one row, then run the rest.

Send maxCostUsd. Loopster estimates the run first, the way a dry run does. If the estimate is over the cap, or the run includes a column with no up-front price and you did not send allowUnpriced: true, nothing is queued and the answer is 422. The cap is a check at the start, not a meter. A run that starts is not stopped part-way, and an AI column's real cost can come in above its estimate.

Send an Idempotency-Key header (MCP: idempotencyKey) so a retry is safe. Use 1 to 128 characters: letters, digits, _, -, . or :. Use a new key for each new action. Repeat the same request with the same key within 24 hours and you get the first answer back, with "replayed": true. Nothing runs or bills twice.

Enrichment is asynchronous and can take minutes, so poll.

For the items call, limit is 1 to 100 (100 by default). Pass the previous nextCursor as cursor. A cursor works only for the run it came from.

A few things to know:

To find which rows of a run failed, list the run's items, then read those rows. In the app, a failed cell shows its message in the cell, and the labels are Error, Unsatisfied and Skipped. See What a cell's message means.

Call GET /v1/tables/{tableId}/rows/{rowId}/trace (get_waterfall_trace). Pass columnId to trace one waterfall column, or leave it out to trace every traceable column on the row. It only reads. It never re-runs anything.

The answer shows:

If successfulProvider is shared_pool, the answer came from Loopster's shared contact pool. No step ran, so attempts is empty. That is free, unless the column verifies its answers and the pooled address had to be checked first. Then the cost is that one check.

You have two brakes. Both prevent further spending. Neither is a refund.

Send POST /v1/tables/{tableId}/stop (MCP: stop_run, which takes a tableId). It stops all ongoing processing for the table. Work that was already charged is not refunded.

The answer reports:

A null count means the worker did not report it. It is not the same as zero. You can call stop twice. With nothing running it reports zero.

Send POST /v1/runs/{runId}/cancel (MCP: cancel_run). It removes the work of one run that is still queued, across the columns it ran. Work already running finishes and is billed.

The answer gives stoppedCells (queued cells removed before they started, with nothing charged) and alreadyRunningCells (they finish and are billed). A row that another run had already queued is not part of this run, so only that run's cancel stops it. Cancelling a run that already finished, or cancelling twice, changes nothing. The answer says canceled: false with the stored status. Any editor in the run's workspace may cancel any run there.

Paid work holds its worst-case cost from your wallet before it runs, and is charged what it really cost, never more. The wallet is never overdrawn.

When a call that would start paid work is refused with a 402, nothing was created, queued or charged. The body carries code, requiredUsd (the most the first row or input can cost) and spendableUsd (what the wallet can spend right now, capped by the workspace's spend limit if one is set). The code says which limit refused the call:

If the refused call carried an Idempotency-Key, the key is released. The same key runs once you have topped up.

To look before you run, read wallet in a dry run. GET /v1/wallet (get_wallet) shows how much the next run can spend, the workspace's plan and any spend limit on the workspace. GET /v1/usage (get_usage) shows what the workspace spent, by table, by column or by day. Amounts are US dollars. The wallet holds real dollars, not credits. See Top up your wallet, set auto top-up and read your funds history and Workspaces: create one and set a spend limit.

A schedule runs columns on a table again and again, on its own. Schedules work over both the API and MCP.

Important: a schedule spends from your wallet every time it fires, with nobody watching, until you pause or delete it. Send paused: true to save one without letting it fire.

To change a schedule, send PATCH /v1/tables/{tableId}/schedules/{scheduleId} (update_schedule). Only the fields you send change, except the timing. The timing is replaced whole: if you send any of cadence, time, timezone, dayOfWeek, dayOfMonth or every, send cadence and time with it.

Yes. A schedule made over the API is stored the way the app's schedule editor stores it, so you can open and change it there. Click Table settings next to the table name. The panel has a Scheduled column reruns section. In the toolbar, Scheduled column runs shows what is scheduled. See Table settings: Auto-run, scheduled reruns and deduplication.

What you see: The trigger answered 200, but triggeredCount is lower than the number of rows you sent.

Why it happens: triggeredCount is the rows that were actually enqueued. deduplicated rows already had a run in progress, and nothing extra is charged for them. rejected rows were refused because the queue is full. They did not start and will not start on their own. unavailable shows only when it is above zero. Those rows could not be confirmed, so they may or may not have started. The four numbers add up to what you asked for, and a message says why when some rows did not start.

What to do: Trigger the rejected rows again. For unavailable rows, retrying an unforced row is safe, because a row that did start counts as deduplicated. Retrying a forced run (force: true) can start a row twice.

What you see: A 503 with code: nothing_started and a Retry-After header, or a 500.

Why it happens: Loopster could not hand the run to its workers, and the request to them was never sent. Nothing was queued and nothing was charged. A 500 with code: nothing_started_internal also started nothing, but it is a fault on Loopster's side, so sending it again now will likely fail the same way. Any other 500 makes no promise: rows may have started.

What to do: After a 503, send the same request again after Retry-After seconds. Use the same Idempotency-Key if you sent one, because this answer is not stored against it. After nothing_started_internal, try later. After any other 500, rows may have started, so check the table's status before you send again.

What you see: A 400, and nothing runs.

Why it happens: A request covers at most 10,000 rows. With no rowIds, a table of more than 10,000 rows is refused. A 400 also comes back when a rowIds entry is not a UUID, when a columnIds entry is not a column of this table, or when none of your row ids belong to this table. If only some belong to another table, those are skipped and listed in notInTable.

What to do: Send rowIds in batches of 10,000 or fewer. Take ids from list rows and list columns. An empty rowIds list runs nothing.

What you see: A 422 with code: cost_cap_exceeded or cost_cap_unpriced_columns.

Why it happens: You sent maxCostUsd, and nothing was queued. cost_cap_exceeded means the estimate is over the cap. cost_cap_unpriced_columns means a column has no up-front price and you did not send allowUnpriced.

What to do: Raise the cap, run fewer rows, or send allowUnpriced: true with the cap. allowUnpriced without maxCostUsd is a 400. This refusal releases an Idempotency-Key, so the same key works once the cap is raised.

What you see: A 402 with code: daily_cogs_limit after you added funds, and spendableUsd is 0.

Why it happens: daily_cogs_limit is the account's daily spend safety limit. It is not a low balance. Topping up does not lift it, and asking for less does not help.

What to do: Wait for it to reset at midnight UTC, or ask Loopster support to raise it. See Contact support.

What you see: A run you expect to be done reads running, or cells is null.

Why it happens: A run is never reported finished in its first 30 seconds. The run list shows what is stored, so it can lag. When another request is still working out the answer, cells is null with a Retry-After header.

What to do: Ask again after the Retry-After seconds. Use GET /v1/runs/{runId} for live counts. If the run items call answers 503 with Retry-After, wait and call it again.

What you see: The calls answered success and the run finished, but some cells failed.

Why it happens: A call can succeed while single cells fail to enrich. The status call counts how many cells errored, but not why.

What to do: List the run's items, find the rows in error, and read those rows. cellErrors in list rows, or get_row, gives the message. In the app, the failed cell says so, and the footer shows a count such as "1 cell failed".

What you see: The wallet went down after you called stop or cancel.

Why it happens: Stop and cancel prevent further spending. They do not refund. Work that was already charged stays charged, and work already running finishes and is billed.

What to do: Read stillRunning in the stop answer, or alreadyRunningCells in the cancel answer. A null stillRunning means unknown, not zero. Next time, price the run with a dry run and send maxCostUsd.

Next: Stop Processing · Cancel a Run · Create a Schedule