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

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

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."
Loading attachments
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.!