CoCart API provides public Rest API endpoints for the development of customer-facing cart, checkout, and product functionality. It follows many of the patterns used in the WordPress REST API. Example of a valid API request using cURL: 
curl "https://example-store.com/wp-json/cocart/v2/products"
Possible uses of the CoCart API include:
  • Obtaining a list of products to display that can be searched or filtered
  • Adding products to the cart and returning an updated cart object for display
  • Obtaining shipping rates for a cart
  • Collecting a customers’s addresses

​
Versioning

CoCart API will be safely versioned using root path versioning, in the format /v{major}. For example, /cocart/v2/cart. The current supported WordPress REST API integration for CoCart is version v2.

​
CoCart API Namespace

Resources in the CoCart API are all found within the cocart/v2 namespace, and since this API extends the WordPress API, accessing it requires the /wp-json/ base. Examples: 
GET /wp-json/cocart/v2/products
GET /wp-json/cocart/v2/cart
The API uses JSON to serialize data. You don’t need to specify .json at the end of an API URL.
If you want to change the CoCart API Namespace, we have an add-on in the works that will do just that. Please show interest by contacting support to be on waitlist.

​
Versioning Strategy

The main principles of the strategy are:
  1. All breaking changes will be bundled into a new version
  2. Deprecations for existing versions whenever a new version is announced is 6 months
  3. In order to provide quicker adoption of new changes, they will be released on on ongoing basis
  4. All API responses will contain the version of CoCart core via the returned header CoCart-Version if you have WP_DEBUG enabled which will be set to the current version of the plugin you are using.
Should there be any fundamental requirement changes that require an API breaking change, we will notify via a blog post.

​
Breaking Changes

Breaking changes are any changes that require developer resources to maintain existing functionality. This includes resources used for investigation into the changes that need to be made, determination of features/endpoints being deprecated and final implementation of all these changes. A list of breaking changes are things like:
  • Removing a param from the API request/response
  • Modifying the name for any params or endpoints
  • Adding/changing optional or required params (e.g., making a customers name a required field in the request)
We won’t make breaking changes to existing API endpoints for API versions lower than v2. If breaking changes are necessary that changes the data in the response, we’ll release a new major version. We may deprecate APIs that have been replaced by a newer version. When doing so, we will expect developers to manage a transition to the new resources within the deprecation timeline of old ones. Changes we do not consider to be breaking:
  • Adding new endpoints
  • Adding optional query parameters to API endpoints
  • Adding new properties to existing API responses
  • Reordering properties in existing API responses
It is important that clients are built to be robust to these changes. Deprecation: Deprecated versions will be unsupported and it is recommended that developers cease to use these APIs. Sunset: Once an API is sunset, the corresponding set of endpoints will no longer be accessible via the API.

​
Requirements and limitations

  • This is an unauthenticated API. It does not require API keys or authentication tokens for access.
  • All API responses return JSON-formatted data.
  • Data returned from the API is reflective of the current user (customer). Sessions are token based.
  • CoCart API cannot be used to look up other customers and orders by ID; only data belonging to the current user.
  • Likewise, CoCart API cannot be used to write store data e.g. settings. For more extensive access, use the authenticated WooCommerce REST API.
  • Endpoints that do allow writes, for example, updating the current customer address, require a cart key or user ID by authentication.
  • CoCart API is render-target agnostic and should not make assumptions about where content will be displayed. For example, returning HTML would be discouraged unless the data type itself is HTML.

​
Pagination

If collections contain many results, they may be paginated. When listing resources you can pass the following parameters:
ParameterDescription
pageCurrent page of the collection. Defaults to 1.
per_pageMaximum number of items to be returned in result set. Defaults to 10. Maximum 100.
Large queries can hurt site performance, so per_page is capped at 100 records. If you wish to retrieve more than 100 records, for example to build a client-side list of all available categories, you may make multiple API requests and combine the results within your application.
In the example below, we list 20 products per page and return page 2. 
curl "https://example-store.com/wp-json/cocart/v2/products?page=2&per_page=20"
Additional pagination headers are also sent back to help determine how much more data is available.
HeaderDescription
X-WP-TotalThe total number of items in the collection.
X-WP-TotalPagesThe total number of pages in the collection.
LinkContains links to other pages; next, prev, and up where applicable.

​
Status Codes

The following table gives an overview of how the API functions generally behave.
Request typeDescription
GETAccess one or more resources and return 200 OK and the result as JSON.
POSTReturn 201 Created if the resource is successfully created and return the newly created resource as JSON.
PUTReturn 200 OK if the resource is modified successfully. The modified result is returned as JSON.
DELETEReturns 204 No Content if the resource was deleted successfully.
The following table shows the possible return codes for API requests.
Status CodeDescription
200 OKThe request was successful, the resource(s) itself is returned as JSON.
201 CreatedThe POST request was successful and the resource is returned as JSON.
204 No ContentThe server has successfully fulfilled the request and that there is no additional content to send in the response payload body.
400 Bad RequestA required attribute of the API request is missing.
401 UnauthorizedAuthentication or permission error, e.g. incorrect login.
403 ForbiddenNot allowed to process this action or have permission.
404 Not FoundA resource could not be accessed, for example it doesn’t exist.
405 Method Not AllowedA request method is not supported for the requested resource.
406 Not AcceptableIndicates that the server could not produce a response.
500 Internal Server ErrorWhile handling the request something went wrong server-side.

​
Route Handling

Typically, routes handle the following types of requests:
  • GET requests to read product, cart, or checkout data.
  • POST and PUT requests to update cart and checkout data.
  • DELETE requests to remove cart data.
  • OPTIONS requests to retrieve the JSON schema for the current route.
Ideally, your server should be configured to accept these types of API requests (POST, PUT and DELETE), but if not you can use the _method property.

​
Dates

Datetime fields in the APIs conform to the ISO 8601 date and time format in UTC. For example: 2025-03-22T11:56:48.520641Z.

​
Country Codes

Countries are identified in the APIs using ISO 3166-1 Alpha-2 codes. For example: GB and US.

​
Currency

Currency are identified in the APIs using ISO-4217 codes. This is a three-letter string like USD or EUR. The value of a currency is represented by your WooCommerce store settings on the General tab. Most currencies have a “precision” of two (like USD: $1.23).
  • AED, VEF, PKR, IDR, HKD, QAR, PHP, NZD, INR, EUR, ARS, THB, MXN, EGP, DZD, SAR, LBP, COP, TRY, SGD, MAD, AUD, USD, MYR, CAD, BRL, GBP.
The following currencies don’t use a decimal:
  • VND, KRW, CLP, JPY
And these use three decimal places:
  • KWD, IQD, BHD, TND
It is important that you set the currency correctly for the API to return price values correctly.