Overview

AuraDB Enterprise AuraDS Enterprise

The Aura API is currently in beta for Aura Enterprise customers only. If you wish to participate in the beta stage, please contact your Customer Success Manager.

The Aura API allows you to programmatically perform actions on your Aura instances without the need to log in to the Console.

A complete list of the available endpoints can be seen and tested in the API Specification.

Before using the API, you must follow the steps outlined in Authentication to create your credentials and authenticate your requests.

API URL

Base URL

The base URL for the Aura API is https://api.neo4j.io.

Versioning

The current version of the Aura API is v1beta3

V1beta3 indicates that this is the third beta release of V1 of the API. Once the API becomes generally available, the version will update to V1.

As and when we need to introduce breaking changes to the API, we will release a new version to ensure we do not break existing integrations.

In the future, as we deprecate legacy API versions, we will provide notice. Once the expiry date for a deprecated version has passed, that version will no longer be available.

Example request

The following example shows how to use the base URL and versioning to make a request to the API:

GET https://api.neo4j.io/v1beta3/instances

Retries

In the event of 5xx server error responses, you may consider retrying the request after a delay if it is safe to do so. The response may include a Retry-After header with a suggestion of a suitable minimum delay before attempting to retry.

Rate limiting is set to 125 requests per minute.

You should consider your use of the Rate Limit before attempting to retry, and we recommend using an exponential backoff delay with a limited number of retries before giving up.

A request is only guaranteed to be safe to retry if it uses an idempotent HTTP method, such as GET. If for example, you attempt to retry a request for creating an instance, you may end up with duplicate instances and end up being charged extra as a result.

In the case of 429 Too Many Requests, we would recommend slowing down the rate of all requests sent from your client application and consider retrying with a suitable minimum delay and backoff strategy.

For other 4xx client error responses, you should not resend such requests without first correcting them.