How to Fix the Clay "recordIds Required" Error When Deleting Rows
The delete request left your browser without the row identifiers, so Clay refused it before touching the table. Nothing was deleted and nothing is inconsistent. Here is the 60-second fix and why logging out beats refreshing.
You select a few hundred rows, press delete, and Clay answers with invalid_type: recordIds Required. The rows are still there. The error is raw JSON, it names a field you have never heard of, and it offers no next step.
This one looks alarming and is not. Clay's delete call expects a list of row identifiers in its payload, and the message means the browser sent that call without one. Three ordinary situations cause it. None of them involve your data being damaged, and all three clear in under a minute once you know which you have.
What invalid_type recordIds Required actually means
The message is a validation error from Clay's own API, not a database failure. When you delete rows, the interface collects the identifiers of everything you selected and sends them as a field called recordIds. The API checks that field before doing anything. If it arrives missing or the wrong shape, the call is rejected and nothing is deleted. The wording is unhelpful, but the behaviour is conservative: it refuses rather than guesses.
| Cause | How you recognise it | Fix |
|---|---|---|
| Expired session | The tab has been open for hours, other actions are also failing | Log out and back in |
| Stale cached scripts | Started after a Clay release, other people are unaffected | Hard refresh |
| Selection lost across tabs | Only happens when the same table is open twice | Close the duplicate tab, re-select, delete |
| Rapid clicks after selecting | Intermittent, usually on very large selections | Re-select, wait for the count to settle, then delete |
| Insufficient permission on the table | Consistent, only on tables you do not own | Ask the table owner for edit rights |
The last row is worth checking early if the error is consistent rather than occasional. Editors can delete tables they own but may have limited rights on tables shared with them, and a permission problem presents in the interface as a failed action rather than a clear refusal.
The 60-second fix
In order. Most people are done after the second step.
Close any duplicate tabs on the same table
If the table is open in two places, the selection state can get lost between them and the delete request leaves with nothing attached. Close the extras first. This costs nothing to try and it is the cause people overlook longest, because the error looks technical enough to seem like a server problem.
Log out and back in
This renews your session token, which is the most common reason the request goes out incomplete. It is more reliable than a refresh for this specific error, because a refresh reloads the page without necessarily renewing the token behind it.
Hard refresh the page
Press Ctrl and Shift and R on Windows, or Cmd and Shift and R on Mac. This clears cached scripts and reloads the current build. If the error started right after a Clay release, your browser is running yesterday's front end against today's API, and this is the step that resolves it.
Re-select and delete, slowly
Click the row selector again and let the selected count appear before you press delete. On a very large selection the interface needs a moment to gather every identifier, and clicking through too quickly sends the request before that list is complete.
Check your rights on the table
If the error persists on one specific table and nowhere else, it is probably permissions rather than session state. Editors can delete tables they own but may have limited rights on tables shared with them. Confirm with the table owner before troubleshooting further.
Stop it coming back
Three habits remove almost every occurrence of this error.
- Work on one tab per table. Two tabs on the same table is the single most reproducible way to lose a selection, and it costs nothing to avoid.
- Refresh at the start of a session. A page left open overnight is running an old front end against a session that may have expired, which is both causes at once.
- Sort out permissions before bulk edits. If you are working in a table someone else owns, confirm you have delete rights before you plan a clean-up around it.
Between them, those three cover session expiry, stale scripts and lost selection state, which is the whole list.
If the problem is a column that never runs rather than a delete that never lands, that is a different failure. We covered it in how to fix Clay columns stuck in queued.
Deletes that do not depend on a browser
This whole class of error exists because the delete is assembled in your browser and sent from there. The identifiers, the session token and the request all live in a tab, so anything that disturbs the tab disturbs the operation.
ReactIn manages list membership server side. Removing a lead from a list, or a list being pruned as its rules change, is processed on our side with identifiers we already hold. There is no payload assembled in a browser, so there is no payload that can arrive incomplete, and a failed operation is retried rather than surfaced as a validation error you have to decode.
The practical consequence is that the state is the same everywhere immediately: dashboards, exports and running campaigns all see the same list, because none of them were waiting on a browser to finish the job.
To be fair: Clay is a spreadsheet-shaped workbench and direct manipulation of rows is the point of it. A browser-assembled delete is the cost of that design, not a defect in it. If you want a table you edit by hand, you accept that the table lives in a tab.
For the other Clay failure that produces no error at all, see why Clay AI enrichments return zero results.
A raw JSON error on a delete looks like something broke deep in the system. It is the opposite: the system checked, found the request incomplete, and refused to act on it.
Frequently Asked Questions
Sources & Further Reading
- Clay's community support has a thread on being unable to delete rows in a Clay table with the session and cache steps.
- The delete endpoint and its recordIds field are described in Clay's API documentation for deleting a row.
- If you would rather rows cleared themselves, Clay documents auto-delete in tables.
Related Articles
How to Fix Expandi Messages Not Sending (Pending Invites)
A connector campaign opens with a connection request, and a lead who already has one pending cannot receive a second. So the campaign has nothing it is allowed to do, and it says so in a tab most people never open.
How to Fix Phantombuster "Error During Loading of Chat Widget"
Phantombuster documents this one, and the documented fix is mostly to wait. The expensive part is a Phantom left looping against it, burning execution time on attempts that cannot succeed.
Working Around the Limitations on Salesflow (2026 Guide)
CSV import exists, so does a campaign type for contacts you already hold, and so do shared blacklists. The constraints that actually bite are narrower: rejected Sales Navigator URLs, per-route caps, and a deliberate block on duplicates.
How to Fix Dripify Lead Collection Stalls (2026 Guide)
Most stalled collections have finished or are waiting. The Lead Collection Report names the cause, the search cap ends runs silently, and working hours suspend lead loading as well as sending.