Whenever you’re using an API, scheduled maintenance windows, connectivity issues, or other general errors could cause calls to be dropped and data to be lost.
When this happens with the Bronto API, don’t be alarmed; you have options.
When the Bronto API encounters an error, it will return a descriptive key, code and message that you can use to determine how you should proceed. Some error types indicate problems that will not be resolved without intervention (INVALID_REQUEST or INVALID_ACCESS as examples), while others indicate temporary problems (SHARD_OFFLINE or READ_ERROR as examples).
You should never assume that every API call will succeed, and you should have a way to store any request that fails, so you do not lose any data due to an issue. You will want to catch any of these temporary errors and queue them up to be retried automatically at a later time.
This will probably involve a catch around your API requests and then logic to store requests that encountered temporary errors to be retried later, while logging the requests that hit more permanent error responses to be evaluated and re-sent differently.
How you implement this will depend on what platform you’re using, but try to write your code in such a way that these types of errors are accounted for and added to a queue so they can be tried again when the issue has been resolved.
The code below will give you a general idea of what we’re talking about.
To access the Bronto API documentation, click here.
For a full list of possible Bronto API error responses, click here.