Handling Errors

When creating objects using the Rutter API, it is important to understand what kind of errors you may encounter and how to handle them.

You can view the full list of Rutter's HTTP Error codes and what they mean here.

Handling Invalid Input Errors

Any request that returns a 4xx response is the result of an invalid input. These requests can be retried. This typically requires the input to be adjusted in a way. Rutter works to ensure that any 4xx request will return an actionable error message in the response body, which will help you understand what went wrong and how to adjust the input.

For idempotent requests that have been accepted and return an invapid input error, you may have to change the Idempotency-Key to retry the request. Read more about making idempotent requests here.

Handling Server Errors

If a request returns a 5xx response, this conveys that an error has occurred in Rutter's servers. Rutter works to make sure this rarely happens.

In the case where a 5xx is returned, you should treat the result of the request as indeterminate, as the object object may or may not have been created. Generally it is not safe or recommended to retry these requests.

Rutter will investigate every 5xx response and make it clear whether or not the object was created.

How Rutter Minimizes Errors in Creating Objects

Every Rutter POST request is backed by an asynchronous job that executes the create operation. During a request, many things can go wrong due to the nature of distributed systems, such as:

1. A database or server call can fail due to transient network errors.
2. A server can return a rate limit error.
3. An error is thrown from server internal logic.

Rutter will intelligently retry errors that are safe to retry (such as a database read or a rate limit error) automatically during the asynchronous job. This minimizes the number of errors that are propagated to you as you use the Rutter API.