REST Update fails with correct info

REST (for Airtable) requires a text field for ID. Testing the Update via Data Configurator with provided record ID yields success. Testing through web interface throws an error:

{"code":"serverError","status":422,"message":"JSON error response from server: {\"error\":{\"type\":\"INVALID_RECORD_ID\",\"message\":\"Value \\\"null\\\" is not a valid record ID.\"}}.","rawError":{"error":{"type":"INVALID_RECORD_ID","message":"Value \"null\" is not a valid record ID."}}}

This happens even though I have an Alert box right before it to confirm the app variable is actually being fed the correct id to the Update Record node.

So, to sum up: Data Configurator tests are successful; app using the same information fails, even confirming info right before execution.

Hi! This sounds odd :thinking: There’s a couple of things you should check:

  1. From chrome developer console, check the network request sent by the app. Is the id included there?
  2. Does the same API call work on mobile, or does it fail similarly?

It also fails on mobile (Android).

Here’s the header for the request. As per the setup for Update Record, the record id appears in the url:

Here’s my node setup - you can see that the alerts track the id from component tap to update record:

…and here, you can see the Update Data configuration (the one used in the above node flow) being successful in it’s test with the identical record id:

…lastly, I updated the last alert to prove the id was present for the Update after the fact:

Capture28d

…such a mystery…

Hmm… Can you show how the update record flow function is configured? Just in case, go check or redo all bindings in case you changed a name of some variable or something, and it’s misconfigured.

Mevi - I’m now hunting to see if this is reporting some other Record ID, not the root. I noticed the error that was returned has 2 repetitive INVALID_RECORD_ID messages, and on troubleshooting I had that reduced to 1, so… conclusion was, they were both referring to separate entities - which made me realize, it’s getting the record fine, just having trouble with its contents (Making a call to an Airtable that has related records returns the ID’s of those related records as a text list).

So, it doesn’t look like a bug - or any true error at all, except how the Data Configurator passes the record while testing, while the regular call does not.

1 Like