EEG Cloud API Documentation

Getting started

The EEG Cloud API allows you to interact with the EEG Cloud platform programmatically. The API is designed to provide access to most of the functionality available in the web interface. You can use the API to create, read, update, and delete data in the EEG Cloud platform, as well as to perform other operations such as starting and stopping captions and downloading data.

General guidelines

The EEG Cloud API follows RESTful principles and has the following characteristics:

• Requests are made by sending HTTP methods like GET, POST, PATCH, and DELETE, depending on the operation you want to perform.
• Responses are typically returned in JSON format, which can be parsed into native data types by any programming language.
• Most POST, PUT, and PATCH requests require a JSON body to be sent with the request.

You can use the EEG Cloud API with any programming language that can make HTTP requests and parse JSON responses.

Note that the Falcon API uses an OpenAPI specification; however, the other APIs do not currently use an OpenAPI specification.

Authentication

The EEG Cloud API uses HTTP Basic Authentication with an API key to authenticate requests. You can create an API key via the API Keys menu item in your account menu.

When using an API key to authenticate requests, use the following Basic Auth credentials:

• Username: api_key
• Password: api_key_123_abc_some_random_value

The API key is a secret that should be kept confidential. Do not share your API key with anyone. If you suspect your API key has been compromised, you can delete it and create a new one.

NOTE: You SHOULD NOT use a username/password combination that works with the HTML website to authenticate requests to the API. While this is currently possible, it is deprecated. Access to the API outside of an API key will be removed in a future release. We recommend using an API key for all API requests to avoid issues with SSO, MFA, and users leaving the organization.

Errors

The EEG Cloud API uses standard HTTP status codes to indicate the success or failure of a request. If you receive an 500 error, please contact us immediately. If your code must check for a 500 in order to function correctly, please consider checking for a 400 error as well. 500 errors are often due to edge case input validation and we will convert those to 400 errors in the future.

Bad requests (400 errors) should contain an error field in the response body that explains the error. We do not consider adjusting the exact text to be a breaking change, so you should not rely on the exact text of the error message for critical logic in your code.