HTTP API - Authorization
Access to the Ditto HTTP API is controlled through an Authorization: Bearer HTTP header. To authenticate and gain access to the Big Peer, use a static API key.
Accessible from the portal, the API key is a straightforward implementation for authenticating your data product's digital identity with the Big Peer for authorization.
The API key is a broad, long-lived HTTP API key that, once generated, remains valid for a maximum of one year.
Ditto implements strong security practices for generating and handling API keys.
- The API key is made up of a combination of random and fixed elements:
- Randomly-generated prefix
- Fixed prefix
- Randomly-generated suffix
- Once received, the Big Peer performs a hashing process on the suffix element before securely storing the API key.
To generate and retrieve the API key you'll include in your request header, from the portal, do the following:
You need elevated access permissions to create and save API keys. You can perform this action only if your assigned role has the Access API keys setting enabled in the portal under Settings > Roles. (See Role-Based Access Control)
Log in to the portal > click Apps > and then select your app from the list.
Click Auth, and then click New API key from the lower right corner.
Complete the Key configuration form:
- For API Key Description, enter a description of the key's intended use.
- For API Key Expiration, if you want to adjust the default date that appears, click the date and then select the date you want from the calendar picker.
- For Read Permissions, select the option you want to set for read permissions.
- For Write Permissions, select the option you want to set for write permissions.
For more information about custom access rules, see Setting Up Custom Permissions, as follows.
Click Create API Key.
From the API key created dialog box:
- Copy your API key and save it in a safe location.
- Once saved, click I have saved my API key, and then click Done.
If you want to scope access to a particular collections or document IDs, set up custom access rules for Read Permissions or Write Permissions:
Select Custom access rules for the operation type you want to set up.
To scope by collection, enter the Collection Name.
To scope by a specific document, from Queries, enter your query expression.
Currently, you can only set permission queries on the _id field; however, Ditto is actively developing a solution for setting queries by mutable fields.
If invoking the FindByID method, instead of using _id, pass the document ID as id.
To add an additional rule, click Add query rule and then repeat step 2 and 3.
Once you've retrieved your API key, you can make requests to the Big Peer by including your key in the Authorization: Bearer HTTP header of each of your requests, as demonstrated in the following POST request:
Most HTTP API errors are indicated with an HTTP Status Code and a JSON response body containing an object with a single "error" key.
In some cases such as a Bad Gateway or Request Timeout only a plain text error or {"message": "Request Timeout"} JSON object is returned.
If you receive a JSON response containing an error field name, its associated field value may be any of the following:
Value | Description |
|---|---|
error.code | The HTTP Status Code for |
error.message | A short description of the error |
error.data | An optional object which contains further elaboration about the error. |
Each write request — either a POST or DELETE request — to the HTTP API represents a distinct transaction; and each transaction may consist of a single operation or multiple operations.
If a request to insert an event successfully executes on the Big Peer, the server includes a transaction ID in its response. You can then include that ID in subsequent GET requests to ensure you're accessing only the most up-to-date and accurate information for that particular event. For more information, see Transaction IDs, as follows.
When retrieving events associated with a specific transaction, ensure data consistency by referencing its unique ID in your GET request. By including the transaction ID, you ensure that you're working with the most up-to-date and accurate information by instructing Ditto to wait until the events related to that transaction have been fully processed and replicated across the entire mesh before being fetched.
If you do not supply the transaction ID in your request, Ditto defaults to using the most recent version of the transaction that is common to all Ditto nodes.
Transaction IDs instruct the Big Peer on the order in which transactions should be applied. For more information, see the Platform Manual > Big Peer.
When making a GET request to find a specific event, instruct Ditto to wait until the associated transaction has been fully applied across the entire mesh network before accessing it. This ensures that you're working with the most up-to-date and accurate information.
To specify a transaction by its associated ID, in your GET request to the find URL endpoint, include the optional X-DITTO-TXN-ID header set to the value of the transaction ID. For example, a returned transaction ID of 14:
If the version of the data being requested is not yet available on the server, an error will be included in the response.