Authentication
API Reference
Section titled “API Reference”Welcome to the Jodo Developer documentation. Our APIs follow a fully RESTful architecture, providing responses exclusively in JSON format, and adhere to standard HTTP response codes, authentication, and verbs.
Authentication
Section titled “Authentication”All the APIs are authenticated using Basic Auth. The required API Keys for Sandbox and Production environments are shared separately.
Errors
Section titled “Errors”When an error is encountered ERP system will receive an HTTP status code along with a message and error code in the body of the response. The message is intended to give a user-friendly explanation of the error while the error codes are designed to be machine readable codes that applications can use to better understand the context of the error and react appropriately.
We use the following status codes for errors:
| HTTP Code | Meaning |
|---|---|
| 400 | Bad Request - The request contains errors. |
| 401 | Unauthorized - The authentication process failed, or the access token is not valid. |
| 403 | Forbidden - Access to this resource is restricted for the given caller. |
| 404 | Not Found - The specified resource could not be found. |
| 405 | Method Not Allowed - An invalid method was used to access a resource. |
| 406 | Not Acceptable - An unsupported format was requested. |
| 409 | Conflict - The requested operation on the resource cannot be made due the resource state. |
| 429 | Too many requests. |
| 500 | Internal Server Error - There was a problem with the Jodo server. Try again later. |
| 503 | Service Unavailable - API is temporarily offline for maintenance. Try again later. |
Rate Limits
Section titled “Rate Limits”Our API employs rate limiting to control the number of requests made by individual users or applications within a specified time period. This ensures the smooth functioning of the API, prevents misuse, and allows fair access to resources for all users.
Handling Rate Limit Exceedance
Section titled “Handling Rate Limit Exceedance”When your requests exceed the rate limits, we recommend that you implement exponential backoff by retrying the request after progressively increasing wait times.
API Update Guidelines
Section titled “API Update Guidelines”Our API is constantly being updated with new features and improvements to existing ones. These updates ensure the API evolves with customer and industry demands. Managing this change to ensure we provide a reliable, consistent, and backward compatible API design is a critical challenge for our team. Every new and improved feature is put through a peer review process to ensure:
- it will not change an existing resource to the extent it breaks current customer implementations,
- that it is consistent with existing resources (therefore predictable and easy to use).
The following guidelines are used in our peer review process to understand what constitutes acceptable change for our API and our customers.
Changes we avoid:
- Removing or renaming request or response content fields
- Removing or renaming query string parameters
- Removing or changing the location of a resource
- Changing the API domain
Changes we approve and introduce:
- Adding new resources
- Adding new, optional request content fields
- Adding new, optional query string parameters
- Adding new response content fields
- Adding new response header information
If, for any reason, we cannot avoid any of the non-backward compatible changes mentioned above, we will implement a deprecation schedule. This schedule will be provided to all customers with the goal of giving them adequate time to accommodate the updates.