The API has a set of HTTP methods to operate on Circuit resources for a specific team.

Currently, Circuit offers no programming SDKs for interacting with the Public API, but you can implement your own interface by calling the methods documented on this page.

This section describes how the Circuit API should be used, if you whish to see example implementations take a look at the API Usage Examples page.

The base API address for this version of the API to be used before every endpoint listed here is: https://api.getcircuit.com/public/v0.2b

Notice the https:// prefix, Circuit API will not accept plain HTTP requests.

To use Circuit Public API endpoints you will first need to generate an API key for authenticating with our servers.

To do this you need to go to your Circuit For Teams settings page > Integrations > API, and generate a new key there.

After you have the API key you can use it in the Authorization header with the Basic Authentication Schema, where the API key you just created is the user, and the password should be empty.

An example request using curl follows:

curl "https://api.getcircuit.com/public/v0.2b/plans" -u yourApiKey:

If you did everything right you should see a list of your team's plans as the response

Every response from the Circuit Public API will be as JSON Objects, and every request that has a body also needs to be in that type, and the header Content-type: application/json needs to present, so the server knows that the body you are sending is valid JSON. Circuit will reject requests without that header, so be sure to use it.

Every resource in the Circuit Public API has a unique ID. This ID is generated by Circuit and is unique for every resource per collection.

Every resource representation returned by the API will show the ID in the following format:

{
  "id": "collectionName/resourceId"
}

And if the resource is on a sub-collection, it will be in the following format:

{
  "id": "collectionName/resourceId/subcollectionName/subResourceId"
}

For example, a stop with ID stop1 under a plan with ID plan1 will have the following representation on its serialized ID field:

{
  "id": "plans/plan1/stops/stop1"
}

This means that if you wish to directly retrieve this stop by using a GET endpoint you can simply use this ID as follows:

curl "https://api.getcircuit.com/public/v0.2b/`serializedId`" -u yourApiKey:

For the example above this would be:

curl "https://api.getcircuit.com/public/v0.2b/plans/plan1/stops/stop1" -u yourApiKey:

When using list endpoints, you have the ability to combine various query options to locate the desired results. Some endpoints even offer specific filter options to aid in this search.

All the list endpoints employ pagination. This means that a single request might only return a part of the entire set of resources you're aiming to retrieve. To move through the subsequent pages, the Circuit API provides a nextPageToken field in the response of every list endpoint query.

It's crucial to understand that when a nextPageToken is returned, it indicates that more data is available. For every subsequent request, this token should be added as the pageToken query parameter. And, importantly, all the original query parameters used in the first request must also be included.

Here's a step-by-step example to elucidate this:

1. Suppose you initiate a request to list your plans:

curl "https://api.getcircuit.com/public/v0.2b/plans?filter.startsGte=2023-05-01" -u yourApiKey:

2. The Circuit API might return a response like:

{
  // other attributes
  "nextPageToken": "I53Jr5Eu2qK9omh0iA8q"
}

3. To retrieve the next page of data, use the returned nextPageToken as the pageToken query parameter, and ensure all initial query parameters remain the same:

curl "https://api.getcircuit.com/public/v0.2b/plans?filter.startsGte=2023-05-01&pageToken=I53Jr5Eu2qK9omh0iA8q" -u yourApiKey:

4. Repeat step 3 for all subsequent pages, updating the pageToken parameter with the latest nextPageToken value returned until nextPageToken is null in the response.

Circuit also accepts limiting the maximum number of results per page by using the maxPageSize query parameter, but notice that each individual endpoint has a maximum value you can set this to.

Update methods differ from the other methods in the API in the sense that missing values in the JSON representation will not act upon the representation of the resource.

Explaining this by example: Suppose you have a Plan with the ID plan1 in your plans' collection, and you wanted to merely update its title to My API Plan without changing other information, such as assigned drivers or the start date. To do this you would issue the following request:

curl -X PATCH http://localhost:5005/public/v0.2b/plans/plan1 -H 'Content-type: application/json' -d '{"title": "My API Plan"}' -u yourApiKey:

Notice how we don't pass any other information in the JSON, only the title. This ensures that the PATCH request will only operate on the provided parameters and keep the other parameters as-is.

It is important to also notice that when updating an array the whole array will be replaced, Circuit API does not support partial updates on arrays.

All the endpoints in the Circuit Public API are rate-limited. This means that we will reject requests if they are coming in too fast.

To know if your request was rate-limited, just check if the response has the HTTP status code 429.

Each endpoint has a different rate-limit, and this rate-limit can be changed by Circuit at any moment.

Most write endpoints currently have a rate-limit of 5 requests per second. Exceptions are:

• The batch-import endpoint has a rate-limit of 4 requests per minute, but can be used to import up to 100 stops at a time;
• The Plan optimization and re-optimization endpoints have a rate-limit of 3 requests per minute, due to the long-running nature of these tasks.

All read endpoints have a rate-limit of 10 requests per second, including the list endpoints.

Circuit API will occasionally support bursts of requests, but this cannot be sustained and will be rejected if it goes on for too long.

When Circuit rejects your request due to exceeding the rate-limiting you will need to wait before retrying the request, we suggest you use an exponential backoff approach for this.

We also recommend, besides the exponential backoff algorithm, that you add a random delay to each attempt, to prevent a thundering herd problem.

If the client keeps on retrying rate-limited requests while being rejected with a 429 at a high rate, Circuit will keep on rejecting the requests until the rate at which requests are made is turned down.

Circuit will also limit requests if it keeps receiving requests at a high frequency at or close to the requests limit for an extended period of time, so we do support occasional burst of requests, but if this is sustained for a long period, we will rate-limit the client making these requests.

After this section you will find all the Circuit Public API endpoints available.

Every representation of resources that these endpoints create and return are documented in the Models page of the docs.

Endpoints to operate on Plans resources.

Endpoints to operate on Stop resources.

For any Plans created before 2023-04-01 the stop collections and all related operations will not be available.

For any operations here you will need a Plan ID beforehand. You can retrieve an existing Plan by listing your Plans or you can create a new one.

Endpoints to operate on Plans resources when it's pending re-optimization and re-distribution.

You must use these endpoints to apply the changes when any Live Stops request returns pending = true.

Endpoints to operate on Stop resources when the plan is already optimized and therefore not writable.

All the endpoints return the field pending. This field indicates whether the change has been applied to the plan or if it's pending a new optimization and distribution. On pending = true, you must use the re-optimize and re-distribute endpoints to apply the changes to the plan.