Clay's HTTP API column works with filtrat out of the box, but its default settings are tuned for fast APIs that answer in a second. Some filtrat checks take longer, so a few settings need changing. Set them on every filtrat column before you run it on a full table.
The settings
| Setting | Value | Why |
|---|---|---|
| Method | POST | Both endpoints take a JSON body. Never GET, never query parameters |
| Body | Raw JSON | Booleans like resolve_catchall must be true, not "true" |
| Response timeout | 90,000 ms (90 seconds) | Resolving a catch-all address can take up to 60 seconds |
| Retry on failure | On | Recovers from brief busy or temporary errors |
| Max retries | 2 | Enough to recover, without piling up requests |
| Status codes to retry | 429, 502, 503, 504 | "Slow down" and temporary errors. Other errors won't succeed on retry |
| Rate limit | 60 requests per 60,000 ms | Our recommended throughput for one column: well under the API's limit, with room for retries |
On API → Clay in the app, the Set these in Clay box under the body shows the same settings.
Where to find them in Clay
Open the HTTP API column's settings. The timeout, the retry options and the rate limit are in the column's optional or advanced settings, below the request body. The rate limit is set as a number of requests and a duration in milliseconds: enter 60 and 60000.
If you set the column up with the Clay prompt, Clay may not apply these settings automatically. Open the column and check them before a big run.
Why the timeout matters most
Most checks finish in a few seconds. Two kinds take longer:
- Catch-all resolution. On a domain that accepts mail for any address, confirming one address takes extra work. It can take up to a minute. See Why resolution takes longer.
- Finding an email. filtrat may try several candidate addresses, and checks the company's real mail domain when the website's domain doesn't receive mail.
With Clay's default timeout, Clay gives up before filtrat answers. The row shows an error, even though filtrat may have finished the work.
Why 60 requests a minute
60 a minute is our recommendation for a Clay column's throughput, not the API's limit. The verify and find endpoints each allow 200 requests a minute per account, shared by all your keys and tools (see Rate limits). A Clay table can send hundreds of requests at once, and anything over the limit gets 429. A steady 60 a minute keeps a column well under it, leaves room for retries and for other tools on the same account, and gives slow rows such as catch-all resolutions time to finish.
If you run several filtrat columns or tables that call the same endpoint at the same time, they share that endpoint's limit. Keep their combined rate well under 200 a minute, for example by lowering each column's rate.
Test before a big run
- Apply the settings.
- Run the column on 10–20 rows.
- Check the results look right and no rows show errors.
- Then run the rest of the table.
If rows still fail, see Rows timing out or failing.