Two Workarounds
-
The first workaround for this is possible if you have control over the service making the webhook call. Simply serialize the entire payload into a single data field, and then extract and parse that field on the Airtable side.
-
The second workaround is to create a proxy service using Autocode. Post the webhook call into your proxy service, serialize the payload into a single added element, and push the augmented payload to its final Airtable webhook endpoint.
Both approaches will require a comprehensive enumeration of payload to handle the anticipated dynamic structure of the data, but that was a given in your scenario at the outset.
I’ve had success with each of these approaches.
Op-Ed
It’s not uncommon for Airtable to paint integration developers into corners like this; there’s a long and storied history of shortcomings like this one. But, this one in particular is a doozy.
They really need to have some senior integration experts on their team who will regularly question the data interchange design, in this case, the inability to foresee that someone might actually want to treat body as a field containing a collection of fields which themselves may also contain additional fields.
In the final analysis,
Is it possible to read a webhook data from a script?
Yes, absolutely. But it is not possible to read [arbitrary] dynamic data, the likes of which tend to occur in more than 50% of the cases.
