Join the Community

Issue with HTTP API Auto-Update Not Re-running Successfully

·

·

I noticed that “Run 1 row” does not re-run HTTP API columns with Auto-update enabled that recently returned a 2xx response. In the attached recording I have recently run the last 3 columns. You can see that the HTTP API column that returns an error queues every time but the Push to Importer column that returns a 200 response does not. Only the first row which had not yet run today queued the second HTTP API call. I have confirmed that unless I see Queued the request is not issued. Based on what I have read it seems like there may be a 24 hour timeout on HTTP API columns with Auto-update enabled. In my use case the HTTP API call is acting as a webhook trigger, so I may need it to run more frequently than once per day. Is there any status code that I can return from that API which will act like a 4xx but not show Error in the cell? I have been testing with GET https://stat.us/205 and similar but it seems like all 2xx codes behave the same in Clay, not repeating the request. All 1xx codes cause the request to hang in Queued state and require stopping manually, and other responses show Error. This is kind of a minor detail since I can just return an error status, but if there is any other way to make sure that ▶️ at the row level always re-runs the column I’m eager to learn! 205 Reset Content seems like the most appropriate status code if you were to choose one non-error status code to behave this way.

9 comments

Channeled
APP
·
·
Currently, there's no built-in way to configure HTTP API columns with Auto-update to run more frequently than once per day. However, you have a couple of options: 1. Use scheduled columns: You can set up columns to run on a schedule, with options for hourly (Enterprise only), daily, weekly, or monthly runs. 2. Manual runs: For more frequent updates, you can manually re-run the column as needed. Regarding status codes, Clay doesn't have a specific non-error status code that ensures re-runs without showing an error. The auto-update behavior is primarily based on the 24-hour cycle, not the status code returned. If you need more frequent updates or a different behavior, you might want to request human assistance for a more tailored solution.
Sources: Scheduled columns | Documentation | Clay University Scheduled columns | Documentation | Clay University HTTP API integration overview | Documentation | Clay University
Ian P.
·
·
That information confirms the behavior that I was seeing. I would like to submit a feature request for a 205 status response to bypass the 24 hour timeout so that running the entire row will re-run the HTTP API column as well, or a similar setting to allow that behavior to be configured in Clay.
Smit V.
·
·
Hi Ian, Thank you for reaching out, and I really appreciate your thoughtful analysis! You’re absolutely right about the behavior you’ve observed: currently, the HTTP columns don’t rerun if their inputs remain unchanged, which helps us avoid unnecessary calls. However, if the input data to an HTTP column changes, it will trigger the column to run again. Thank you also for suggesting the addition of status 205. I’ll make sure to share this feedback with our product team. Let me know if I can help you with anything else :)
Ian P.
·
·
Thank you! That makes a lot of sense. This is an oddball case since we're trying to avoid sending the full data and introducing a maintenance headache in the API call config, but I have a few ideas to tets now that could work.
Smit V.
·
·
Thanks for your understanding, Ian! I agree, it’s definitely a unique scenario, and I appreciate you thinking creatively about possible solutions. If you’d like to bounce any ideas off me or run into any challenges while testing, just let me know, I’m here to help however I can. Good luck experimenting :)
Ian P.
·
·
So far it seems like the easiest way to approach this is with a custom header that includes all of the fields we want to monitor in any order. I originally tried the same concept with the JSON request body (wrapping all fields in one set of quotes) but it looks like there may be a bug rendering adjacent interpolated values inside a JSON string (second screenshot) and this also seems more error-prone than a header that can safely be ignored. First attempt was a run condition like true || /Issued || /Website || /Tradename but that didn't trigger the request to re-run on changes to those fields (understandably). I like it, this is easy enough for me to document and makes it crystal clear that triggering the HTTP call on updates is not done by "magic."
Smit V.
·
·
That sounds like a solid approach. Using a custom header to track the fields is straightforward and avoids the JSON interpolation issues you ran into. Plus, it makes the trigger logic clear and easy to document. Let me know if you need any help :)
1
Channeled
APP
·
·
Channeled
APP
·
·
Thank you so much for sharing your feedback Ian P.!