Skip to main content
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:
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:
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:
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.
Additional pagination headers are also sent back to help determine how much more data is available.

​
Status Codes

The following table gives an overview of how the API functions generally behave. The following table shows the possible return codes for API requests.

​
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.

​
Response Headers

CoCart returns specific and required headers for the API to function and help manage data control.

​
Global Headers

If you have WP_DEBUG set to true, the version of the core of CoCart will return. In addition a timestamp header is also introduced.
  • CoCart-Version: 4.6.3
  • CoCart-Timestamp: time()

​
Cart Headers

For the Cart API, three important headers return for managing the cart session. Use them to help track the cart session.
  • Cart Key: CoCart-API-Cart-Key:
  • Cart Expiring: CoCart-API-Cart-Expiring:
  • Cart Expiration: CoCart-API-Cart-Expiration:

​
CORS Headers

When CORS is enabled, the following headers will return.
  • Access-Control-Allow-Methods: OPTIONS, GET, POST, PUT, PATCH, DELETE
  • Access-Control-Allow-Credentials: true
  • Vary: Origin
  • Access-Control-Max-Age: 600 - This caches the result of preflight requests (600 is the upper limit for Chromium).
  • X-Robots-Tag: noindex
  • X-Content-Type-Options: nosniff
Allowed preflight requests and any allowed origins will return:
  • Access-Control-Allow-Origin: *

​
Cache Control

  • Expires: Thu, 01-Jan-70 00:00:01 GMT
  • Cache-Control: no-cache, must-revalidate, max-age=0, no-store // If the API is authenticated it will extend by adding private at the end.
  • Pragma: no-cache
The products API additionally returns the last modified header with the date of the product it was last updated.
  • Last-Modified: Thu, 29-July-25 14:05:30 GMT

​
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.