Hey Clay S. did the default behavior around referencing columns in HTTP payloads change? In the past you would do something like this:
.png){kind=logo}
{
"key": /ColumnName
}and that worked. starting today we've had several customers complain that they are getting parse errors and they now need to do
{
"key": "/ColumnName"
}
👋 Hey there! Our support team has got your message - we'll be back in touch within 24 hours (often sooner!). If you haven't already, please include the URL of your table in this thread so that we can help you as quickly as possible!
Hi Julian, thanks for reaching out. Taking a look at this now.
Hey Bruno - great thanks!
That’s right! We made changes to improve input parsing for dynamic tokens. Now, you must enclose dynamic variables in quotation marks when using the HTTP API enrichment column. In standard JSON, strings and tokens (like "{{dynamic_token}}") require quotes, while numbers (e.g., 123) do not. For arrays, strings need quotes (e.g., ["apple", "{{token}}"]), but numbers don’t (e.g., [1, 2, {{number}}]). Following these rules ensures the API processes inputs correctly. Were you able to get it working?
Hmm interesting ... was there any kind of email or announcement about this? I'd imagine this would break a LOT of http requests for customers
Hi Julian, this was designed not to affect past table setups. These are rules that will only be impacting new HTTP API setups.
Eeek even more confusing! Curious, what happens if a user copies a table or reuses a saved template - does it use the new format and stop working? Thanks for all the info on this Bruno!
Thanks for following up on this, Julian. This approach shouldn’t cause any issues with the workflow, as the JavaScript functions used to send the HTTP API requests won’t interfere with how the underlying dynamic tokens are handled. Let me know if you have any issues with the workflow setup or duplication process and I'll be happy to take a look at what's causing the issue here.
And when you say "past table setups" - right now we have a public template we share with our customers. This template was created weeks ago. If a user adds this template to their workspace is that considered before/after the changes? Trying to understand if we need to update our templates
You should not have to update your templates, the change should not affect existing workflows or templates with HTTP API setups.
I only ask cause we just had a few customers today things were broken - so trying to understand where it's breaking. The terminology can be a bit confusing - so just want to make sure we are on the same page! Right now the way we are set up is that we have:
TABLE level templates we share with customers. They add these to their workspace.
Those tables have HTTP API enrichment columns that are using the old style (i.e "key": /Column )
Sometimes customers take those columns and save those as HTTP API Templates so that they can reuse them in other existing/new tables
I'm a bit confused as to how clay is determining when to apply the new logic vs. when not to. Let me know if that makes more sense!
Follow up question - if I now UPDATE our existing table template will it use the new style or the old?
Just heard back from one of the customers who's workflow was broken and they said they ran into this in #3 - where it was a table they created today and reused an HTTP API Template they had saved before
Was there any kind of announcement or link talking about this and explaining the behavior a bit more? Getting more pings from customers who are confused so just want to make sure I can give them proper guidance - thanks!
Hi Julian! 😊 I understand the confusion around the new and old logic for HTTP API enrichment columns, especially with customers reusing saved templates. Here’s a breakdown: • The recent switch was necessary because AI was frequently recommending users to include quotation marks in a way that didn’t align with how most API providers operate. During a recent hackathon, we addressed this issue and are working on new AI features, like Quick Start for HTTP API, which will make the process even smoother. • Moving forward, if you update your existing table templates, they will now use the new style. However, older templates should still work as they did before since we’re keeping both JSONify tokens functional for compatibility. If any workflows are breaking for customers, I recommend creating a new HTTP API enrichment and writting manually (not copy/paste) their old templates to align with the new logic. Here’s a video that can help walk them through it: Loom Video. Let me know if you need any more help or further clarification! 👏
okay so sounds like we should UPDATE the table templates to use the new style of explicitly wrapping the columns with quotations. and then we can switch to the formula view and ensure that we have the new clay function to make sure it's the new style? does that sound right Bo?
Yes, updating the table templates to use the new style with explicit quotations around the columns would be a good move! While it’s not strictly necessary, the new style is more in line with current standards and will be supported moving forward, whereas the old style won’t be around forever. Let me know if you need any help switching to the new format! 👏
thanks Bo!