Issues with Slow Responses in HTTP API Enrichment

Ibra S. · 2026-01-01T08:25:11.415Z

I am having trouble using the HTTP API enrichment. The API I'm using is working well but clay is being super slow with getting the responses. Workbook: https://app.clay.com/workspaces/361467/workbooks/wb_0t7rvm4FqcEX4B4QDMh/tables/t_0t7rvm4NdVC7BR3X7U5/views/gv_0svklbmC5zPVVkQD25Q

Issues with Slow Responses in HTTP API Enrichment | Clay

11 comments

· Sorted by Oldest

Clay Support
APP
·
·
HTTP API slowness can happen for several reasons. First, check if you've configured rate limits properly - if your API has limits, set them in the enrichment settings to avoid hitting rate limit errors. [1]
Performance issues are also common with larger tables or when multiple actions run simultaneously, which can cause latency where data takes longer to load. Try a hard refresh (Cmd+Shift+R on Mac or Ctrl+Shift+R on Windows) to see if that helps.
For better troubleshooting, can you copy and paste your JSON configuration from the HTTP API column into the chat? This will help me identify any formatting issues that might be causing slowdowns.
Also consider testing with just one row first to verify your configuration works properly before running on the full table.
Ibra S.
·
·
I have tried all this. Please call a human.
Clay Support
APP
·
·
Got it — I’m connecting you to a human teammate now. Thank you for your patience.
Clay Support
APP
·
·
Our support team has got your message and we'll get back to you soon! We're currently outside of our standard office hours (9 AM to 9 PM EST, Monday through Friday), so it may take a little longer for us to respond.

If you’re dealing with a specific table, drop the URL below so we can help you quicker. Otherwise, someone from our team will be in touch soon!

image.png(93 kB)
Ibra S.
·
·
https://app.clay.com/workspaces/361467/workbooks/wb_0t7rvm4FqcEX4B4QDMh/tables/t_0t7rvm4NdVC7BR3X7U5/views/gv_0svklbmC5zPVVkQD25Q
Bo (.
·
·
Hey,
We don’t control the API’s response time. What Clay does is send the request and wait for the API to respond, so the speed depends on how quickly that API returns.
That said, nothing looks like it’s blocking responses on Clay’s side. The main thing that can make it feel slow here is concurrency and retries:
If you’re running a large table, requests get queued and processed with concurrency limits.
I’m also seeing a very high rate limit behavior. If your API rate limits you, Clay will retry failed requests.
Those retries compound over time because we send a request, it fails due to rate limit, then we try again, and that can slow down the whole run.
That also explains why only a small number of cells were processed so far.
Let me know if you have more questions.
Ibra S.
·
·
Bo, the issue is from clay side. Please watch this loom for explanation: https://video.ibrasawool.com/oubT6CclC6UYxgY_
Bo (.
·
·
Hey,
I watched the video. What you’re seeing is expected behavior. The provider is rate limiting the requests on their side. From our end, we’re sending a high volume of calls, and once that threshold is hit, the provider applies the limit.
That rate limit applies at the workspace level, not just a single column or table. So even if individual rows look fine, the provider will still throttle new requests until the limit window resets.
Let me know if you have more questions.
Ibra S.
·
·
Bo, this isn't helping at all. As I showed, even if caly is sending those requests, we can't see the connections. Therefore, clay is not sending the requests or it will work. The rate limit for my key is 5 requests per second. And its not even working at that level.
Bo (.
·
·
Hey,
The requests are absolutely being sent. What you're not seeing in your API logs is the full picture of what's happening at the workspace level.
Here's what's actually going on. When you test your API directly, you're sending one request at a time and getting instant responses. In Clay, you're running this enrichment across multiple rows simultaneously. Even though your API supports 5 requests per second, Clay is sending way more than that because you've got multiple columns, multiple tables, or other enrichments running in your workspace at the same time hitting the same API.
Your API provider sees this flood of requests coming from Clay and starts rate limiting them. When that happens, Clay receives rate limit errors back from the API and automatically retries those failed requests. Those retries stack up and create the slowness you're seeing. The requests are sent, they just fail and get queued for retry.
This is why you're only seeing a small number of successful cells in your table. Most of the requests are hitting the rate limit and cycling through retries.
If you're running other tables or enrichments that hit this same API, pause those first, then run your current table with the lower rate limit.
Clay Support
APP
·
·
We haven't heard back from you here, so we're going to go ahead and close this thread out.

Still need help here? Reply back and someone will jump back in.

Have a question thats not related to this thread? We recommend kicking off a new ticket in the support channel!

Clay Support
APP
·
·
HTTP API slowness can happen for several reasons. First, check if you've configured rate limits properly - if your API has limits, set them in the enrichment settings to avoid hitting rate limit errors. [1]
Performance issues are also common with larger tables or when multiple actions run simultaneously, which can cause latency where data takes longer to load. Try a hard refresh (Cmd+Shift+R on Mac or Ctrl+Shift+R on Windows) to see if that helps.
For better troubleshooting, can you copy and paste your JSON configuration from the HTTP API column into the chat? This will help me identify any formatting issues that might be causing slowdowns.
Also consider testing with just one row first to verify your configuration works properly before running on the full table.
Ibra S.
·
·
I have tried all this. Please call a human.
Clay Support
APP
·
·
Got it — I’m connecting you to a human teammate now. Thank you for your patience.
Clay Support
APP
·
·
Our support team has got your message and we'll get back to you soon! We're currently outside of our standard office hours (9 AM to 9 PM EST, Monday through Friday), so it may take a little longer for us to respond.

If you’re dealing with a specific table, drop the URL below so we can help you quicker. Otherwise, someone from our team will be in touch soon!

image.png(93 kB)
Ibra S.
·
·
https://app.clay.com/workspaces/361467/workbooks/wb_0t7rvm4FqcEX4B4QDMh/tables/t_0t7rvm4NdVC7BR3X7U5/views/gv_0svklbmC5zPVVkQD25Q
Bo (.
·
·
Hey,
We don’t control the API’s response time. What Clay does is send the request and wait for the API to respond, so the speed depends on how quickly that API returns.
That said, nothing looks like it’s blocking responses on Clay’s side. The main thing that can make it feel slow here is concurrency and retries:
If you’re running a large table, requests get queued and processed with concurrency limits.
I’m also seeing a very high rate limit behavior. If your API rate limits you, Clay will retry failed requests.
Those retries compound over time because we send a request, it fails due to rate limit, then we try again, and that can slow down the whole run.
That also explains why only a small number of cells were processed so far.
Let me know if you have more questions.
Ibra S.
·
·
Bo, the issue is from clay side. Please watch this loom for explanation: https://video.ibrasawool.com/oubT6CclC6UYxgY_
Bo (.
·
·
Hey,
I watched the video. What you’re seeing is expected behavior. The provider is rate limiting the requests on their side. From our end, we’re sending a high volume of calls, and once that threshold is hit, the provider applies the limit.
That rate limit applies at the workspace level, not just a single column or table. So even if individual rows look fine, the provider will still throttle new requests until the limit window resets.
Let me know if you have more questions.
Ibra S.
·
·
Bo, this isn't helping at all. As I showed, even if caly is sending those requests, we can't see the connections. Therefore, clay is not sending the requests or it will work. The rate limit for my key is 5 requests per second. And its not even working at that level.
Bo (.
·
·
Hey,
The requests are absolutely being sent. What you're not seeing in your API logs is the full picture of what's happening at the workspace level.
Here's what's actually going on. When you test your API directly, you're sending one request at a time and getting instant responses. In Clay, you're running this enrichment across multiple rows simultaneously. Even though your API supports 5 requests per second, Clay is sending way more than that because you've got multiple columns, multiple tables, or other enrichments running in your workspace at the same time hitting the same API.
Your API provider sees this flood of requests coming from Clay and starts rate limiting them. When that happens, Clay receives rate limit errors back from the API and automatically retries those failed requests. Those retries stack up and create the slowness you're seeing. The requests are sent, they just fail and get queued for retry.
This is why you're only seeing a small number of successful cells in your table. Most of the requests are hitting the rate limit and cycling through retries.
If you're running other tables or enrichments that hit this same API, pause those first, then run your current table with the lower rate limit.
Clay Support
APP
·
·
We haven't heard back from you here, so we're going to go ahead and close this thread out.

Still need help here? Reply back and someone will jump back in.

Have a question thats not related to this thread? We recommend kicking off a new ticket in the support channel!