Cuvrd Developer Docs

Cuvrd API Reference

Learn how to integrate our products into your environment

Logo

Overview


Cuvrd provides a collection of API tools that allow your users to, among other things, obtain quotes for service contract coverage and book service contracts directly into our contract management system.

We have both REST and GraphQL APIs that are easy to understand and integrate into your backend systems.

Most of our APIs also have companion UIs, so if you'd like to get started with us before your dev is complete, contact us and we can get you set up.

We're happy to help if you have any questions—just let us know!

Sample requests


We provide sample API calls next to each method using cURL. All you need to do is insert your specific parameters, and you can test the calls from the command line. See this tutorial on using cURL with APIs.

You can also use Postman if you aren't familiar with cURL. Postman is an easy to use API development and testing platform. If you prefer to work with our Postman collection, contact us for access to the latest version.

Authentication


Unless otherwise noted, credentials are passed to the API in the body of the request. There is no need to pass authentication credentials as a header.

Credentials are assigned to your organization once you sign up with Cuvrd.

Examples in the documentation have testing keys embedded. These keys will only work in our testing environment, and can be changed or revoked at any time.

Versioning


REST API versioning


Cuvrd REST APIs are versioned. The most current version of each REST API is noted in the menu. Current point releases are noted in each APIs response.

Any breaking changes will be released in a new API version. Breaking changes are changes that can potentially break an integration. Breaking changes include:

  • removing an entire operation
  • removing or renaming a parameter
  • removing or renaming a response field
  • adding a new required parameter
  • making a previously optional parameter required
  • changing the type of a parameter or response field
  • removing enum values
  • adding a new validation rule to an existing parameter
  • changing authentication or authorization requirements

Any additive (non-breaking) changes will be available in all supported API versions. Additive changes are changes that should not break an integration. Additive changes include:

  • adding an operation
  • adding an optional parameter
  • adding an optional request header
  • adding a response field
  • adding a response header
  • adding enum values

Versions are specified in the API's URL.

When a new REST API version is released, the previous API version will be supported for at least 24 more months following the release of the new API version or until all active partners have stopped using the deprecated API.

Although documentation will remain available deprecated API versions, you should only develop against the most recent version, as vendor credentials will only be valid for the current version at the time of credential assignment and newer versions.

GraphQL API versioning


As with Cuvrd REST APIs, our GraphQL APIs are versioned as well. The most current version of each GraphQL API is noted in the menu. Current point releases are noted in each APIs response.

Any breaking changes will be released in a new API version. Breaking changes are changes that can potentially break an integration. Breaking changes include:

  • removing an entire operation
  • removing or renaming a parameter
  • removing or renaming a response field
  • adding a new required parameter
  • making a previously optional parameter required
  • changing the type of a parameter or response field
  • removing enum values
  • adding a new validation rule to an existing parameter
  • changing authentication or authorization requirements

Any additive (non-breaking) changes will be available in all supported API versions. Additive changes are changes that should not break an integration. Additive changes include:

  • adding an operation
  • adding an optional parameter
  • adding an optional request header
  • adding a response field
  • adding a response header
  • adding enum values

When a new GraphQL API version is released, the previous API version will be supported for at least 24 more months following the release of the new API version or until all active partners have stopped using the deprecated API.

Although documentation will remain available deprecated API versions, you should only develop against the most recent version, as vendor credentials will only be valid for the current version at the time of credential assignment and newer versions.