Our APIs adhere to the REST standard using standard HTTP methods, which accept JSON-encoded payloads and return either JSON responses or binary files (application/pdf). All endpoints require authentication via bearer tokens and follow standard HTTP response codes to indicate request status.

Request API Access - ready to start using our APIs?

• API Request Form API Request Form - Please complete the API Request Form only if you are ready to proceed with obtaining API access.
• After submitting the API Request Form, please allow up to 3 days to receive your API credentials, provided there are no issues with your account or configuration method.

Authentication

All API calls require bearer token authorization, please see the Authentication page for detailed documentation about the process.

Authentication Scopes

A scope defines the permissions or access levels granted to a token for specific API resources or actions. A valid scope must be sent with the authentication request in order to gain access to the desired endpoint. The necessary scope for each API is defined at the beginning of the API specification document.

Customer Types

Customer types refer to the parties interacting with the resource. These include:

• SHIPPER (which also covers Brokers and Dealers)
• CARRIER

All endpoints can be used by any customer type unless specified otherwise in the API specifications.

Version Request Header

When making API requests, you must specify which version of the API you want to use. This is done by supplying a custom MIME type that contains vnd.coxauto.v[#]+ in the Accept and/or Content-Type headers. For example, to request a resource from version 1.x.x of an API, the Accept header should be set to application/vnd.coxauto.v1+json.

All requests with bodies (POST, PUT, PATCH) must pass the value in the Content-Type header.

All other requests (GET, DELETE) must pass the value in the Accept header.

If the Content-Type header cannot be used for some reason, the value must be passed in the Accept header.

Etag and If-Match Headers

• ETag Response Header An ETag (Entity Tag) is a version identifier for the resource. Many of the API GET calls will return an ETag response header. This value should be used when making a subsequent update to the resource and is usually required to be passed in the If-Match header.
• If-Match Request Header The If-Match header helps prevent multiple users from accidentally overwriting each other's changes. The value is the version identifier for the resource. Most resource update API calls require this header value. To retrieve the value, perform a GET call and look for either the ETag response header or the RecordVersion in the response body.

Location Response Header

API calls that create a resource will return a Location response header that contains the fully qualified URL of the newly created resource. The resource ID will be the last segment of the URL. Example: https://api.centraldispatch.com/resources/id/12345

You will need to make a GET call to retrieve this value before making updates on most resources.

Date and Time Properties

Unless otherwise indicated all date/time properties are represented in ISO 8601 formats. Time values must be sent in UTC or include the appropriate time offset. The application will store and return all date/time fields with no offset.

What you send: "availableDate": "2025-11-05T10:00:00-05:00" (10:00 AM EST) vs. what gets stored and returned: "availableDate": "2025-11-05T15:00:00.000Z" (Converted to UTC).