In almost every API integration, more than half of the code and logic required (to do it well) is generally related to error handling. In your example, there should near-zero ambiguity concerning the outcome of the POST process and if such process resulted in success (or failure).
When your app makes a post request, you should get a response and that response (almost invariably) will either contain a copy of the record added (or updated) represented in JSON (stringified) format or it will contain an error also represented in JSON (stringified) format. You shouldn’t have to go check to see if it was created (or updated) if your API process has been designed to factor in at least two possible outcomes and revealed in a easy-to-review manner.
One approach that I like to use when building Airtable solutions is to log API activity to a table - like Airtable itself using a well-tested coding framework that simply snaps into every project. The log is updated on three dimensions -
- When an attempted API call encounters a syntax error
- When an attempted API call results in an error response
- When an API call results in success
I don’t typically keep such logging active beyond the testing phase, but during the development and testing phase, this approach provides clarity on your API integration progress.
