Provisioning API

Overview

API versions

Please note that newer versions of this API may include pure additions to it (such as new properties on resources returned from an action, accepting these resources with or without the property inbound to the server, or adding new resources or actions), or new appearance of properties within JSON structures because we assume that clients use forgiving, non-strict parsing on the JSON they receive from Devo.

New versions of the API will always be backwards compatible, using a never remove, only add strategy. Contact us if you have any questions.

The Devo Provisioning API can be used to:

Retrieve information on users and domains.
Create, update, delete and modify Devo domains, and also enable or disable them.
Create, update, delete and modify Devo users, and also enable or disable them.
Get lists of available multitenant domains and users in a specific domain.
Retrieve and update a domain's plan configuration and ingestion limits in Devo.
Retrieve lists of plans associated to a multitenant and information on specific plans.
Get the certificates associated to specific Devo domains.

To perform a request with the Provisioning API, use the endpoint corresponding to your Devo region. See the Devo Provisioning API documentation in Swagger to see in detail the paths and parameters you can add to your endpoint URL in order to perform the available types of requests:

Region	Endpoint	Swagger documentation

Region	Endpoint	Swagger documentation
USA	`https://api-us.devo.com/probio`	https://api-us.devo.com/probio/apiDoc/index.html
EU	`https://api-eu.devo.com/probio`	https://api-eu.devo.com/probio/apiDoc/index.html
CA	`https://api-ca.devo.com/probio`	https://api-ca.devo.com/probio/apiDoc/index.html
Asia-Pacific (APAC)	`https://api-apac.devo.com/probio`	https://api-apac.devo.com/probio/apiDoc/index.html

Every Provisioning API response sends a special header named x-devo-cid, which contains the correlation ID generated for the request. In case of any problem, contact us and include this value in the message so that we can trace the problem more effectively.

Names format

Common and multitenant domain names

The name format for common and multitenant domains is not the same. Common domains have regular names (with certain character restrictions, but they don't need to follow a fixed format), while multitenant domain names are followed by the name of the multitenant they belong to, separated by an @ (domain_name@multitenant).

This tail can be ignored when you create a new multitenant domain, but keep in mind that it must be added in all the operations that require the name of the domain; otherwise, they will return an error. For example, if you create a domain called my_domain in the multitenant test, you will have a domain called my_domain@test. Any further operations will require this name format to work properly.

Name validation

Regular names, like domain names, can only contain specific characters and should match the regular expression [a-z0-9_-]{1,100}. Essentially, this requires the name to have a maximum of 100 characters, and only use lowercase letters, numbers, or the special characters _ and -.

User names have fewer restrictions, allowing things such as accents, dots, @ characters, etc.