All API requests must be directed to the
https://api.quantcdn.io/v1/. The path is prefixed with the API version. If backwards-breaking changed are introduced into the API the version number will be bumped, old versions of the API will be maintained and deprecated with plenty of notice. You will need to add specific headers to each request to ensure that the API endpoint can correctly identify you.
In CURL a request will look like;
Quant uses bearer tokens for authentication. All requests must specify the
Quant-Token request header and need to send the value presented in your dashboard. If you haven't created a project head over to your dashboard set one up to retrieve your token and start publishing!
To further identify your request you are required to add
Quant-Project request headers. These will be validated against the
Quant-Token to ensure that the request is valid.
Requests that return multiple items will be paginated to 100 items by default. You can specify the
page query parameter to iterate through the result set. You can also change the number returned by quant with the
Paginated API endpoints will return data under a
Paginated result sets will include metadata to help identify how many results are available for any given call. These are available in the result object as
The most common API action is sending content, either new content or a content revision. Quant supports two types of files;
- HTML (markup)[#sending-markup] as pages
Quant is based on atomic deployments, each time a file changes Quant treats it as if a new file was submitted to the API. This allows Quant to show point in-time representations of any asset that has been sent to Quant.
This is the main action of the Quant API and is how we register paths and content to be served from those paths. When you send markup you will need to tell Quant what URL this markup will be accessible by, if the content is published and additional metadata.
The Quant API will scan your markup and identify assets. It will respond to your request with a list of assets that already exist in Quant (along with md5 values) so you only need to push files that have changed or do not already exist.
You may optionally provide custom headers along with the content payload. This allows fine-grained control of the headers that are emitted for each individual piece of content. Simply include key/value pairs under the
This approach is useful for machine-readable content that is not markup. It allows for this content to be sent inline rather than as a binary file.
To add a URL for the file you need to specify the
Send markup before binary files. The response will show any files already in Quant and reduce the number of API requests you need to make to seed your static website.
As with content, files may also present custom headers. These are passed in as encoded JSON using the
Quant-File-Headers header on the POST request.
This is generally not required during normal operation, but included for completeness. Common headers expected for binary files such as
Content-length are automatically determined.
When you request metadata about your site, Quant will send a paginated API response containing information about your files that is not served to end users. This includes information like the published revision, the number of revisions, where the file is accessed and more.
The endpoint requires the standard authentication headers described above.
You may query for the metadata of individual URLs using the
PATCH /unpublish instructs Quant that a particular path is no longer accessible. This will cause Quant to issue a 404 for the path instead of the content stored for the path.
PATCH /publish/[REVISION_ID] allows a previous revision to become the actively published content. You may retrieve revision ids via the metadata endpoints.
POST /redirect creates a redirect.
This allows you to redirect one path to another when Quant is serving pages. You can control the status code that quant serve when you create this redirect.
POST /proxy creates an origin proxy.
This will cause Quant Serve to pass the request directly back to the origin server.