Learn about the conventions of OrderCloud and how the APIs predictable nature enables extreme interoperability.Suggest an edit
The OrderCloud API adheres to a RESTful architectural style. URIs, HTTP verbs, headers, payloads, and response codes all follow consistent and predictable patterns. This doc will outline conventions that permeate the entire platform.
API access is only allowed via HTTPS; connections on port 80 are refused entirely. This simplifies the token-based authentication.
UTF-8 encoded JSON is currently the only supported data format for both request and response payloads.
Dates/times returned in the API are in UTC time and conform to ISO 8601.
Writable IDs can be extremely useful for back-office integrations as they can eliminate the need for a mapping middleware layer.
Most resources that map to an entity of some sort (Orders, Users, Addresses, etc.) contain an ID that is optionally writable on creation or update. If you do not pass one, one will be auto-generated and returned in the response, and will be guaranteed to be unique. If you choose to pass an ID, you are responsible for ensuring uniqueness. Things that live under the context of a single Buyer need only be unique within that context. Things that are shared (such as products) must be unique across the entire Seller organization.
For all unsuccessful requests, we attempt to return the most appropriate HTTP status in the 400 range. Only when something goes terribly wrong on our end will you get a 500 response. And so long as our platform is responding (i.e. returning anything in the 4xx range or 500), you can count on the response body taking a standard shape.
A resource is a set of endpoints used to interact with an object of that same name. OrderCloud adheres to RESTful conventions in its usage of HTTP verbs. You can expect a subset of the following methods to exist on every Resource.
|OrderCloud Verb||HTTP Verb||Meaning||Example|
|GET||GET||Returns a specific item||Get a single address|
|SAVE||PUT||Create or replace an item, you provide a unique ID||Create address ABC, overwriting it if it already exists|
|PATCH||PATCH||Use it for updating items||Update the name on an address by providing the new name|
|LIST||GET||Returns a list of items||Get a list of addresses|
|CREATE||POST||Creates a new item, we generate a unique ID if no ID is provided||Create a new address|
|DELETE||DELETE||Deletes an item||Delete address ABC from the database|
OrderCloud uses conventional HTTP response codes to indicate success or failure of an API request. In general, codes in the
2xx range indicate success and codes in the
4xx range indicate an error failed given the information provided (e.g., a required parameter). Only when something goes terribly wrong on our end will you receive a
500 response. As long as the platform is responding you can count on the response body taking a standard shape.
|Status Code||Suggested Course of Action|
|200 - OK||Everything worked as expected. No action required.|
|201 - Created||Something has been successfully created. No action required.|
|204 - No Content||The server has successfully fulfilled the request. No action required.|
|401 - Unauthorized||The user is not authorized to make a call to the API. Check that user credentials are valid and that there is a token on the headers in the format: `Bearer eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9...`|
|403 - Forbidden||The user's Security Profile does not have the necessary roles to make the API call. Update Security Profile to include valid roles for the call. The response will include a list of the missing roles|
|400 - Bad Request||Something was wrong with the request. Use the response from the API to determine the corrective course of action.|
|404 - Not Found||The requested resource was not found. A common reason for this is a bad request.|
|500 - Internal Server Error||There was a server-side issue. Please contact us if you encounter this error code.|