...
| URL | Swagger Gui | Swagger JSON | Note |
|---|---|---|---|
https://api-no.drofus.com | API documentation and test it in web GUI | Open API Specification | use for db2.nosyko.no projects |
https://api-eu.drofus.com | API documentation and test it in web GUI | Open API Specification | |
| https://api-ca.drofus.com | API documentation and test it in web GUI | Open API Specification | |
| https://api-us.drofus.com | API documentation and test it in web GUI | Open API Specification | |
| https://api-au.drofus.com/ | API documentation and test it in web GUI | Open API Specification |
For API versions newer than 4.20, urls should contain database and projectId. Ie. when previously getting rooms from http://xxx/api/rooms, now rooms should be read from http://xxx/api/database/projectid/rooms
Authentication
...
Authentication
Bearer
API generally supports OAauth2 standard Bearer tokens. Registration process of OAuth2 client is currently manual, please reach out to support@drofus.com and we can provide needed information. .
Providing database and projectId in username
Preferably, database and projectId should be specified in URLs, but we still support providing it in usernames, on the form <db-name>/[project-id/]user-name[/language], where:
...
Please send us the desired redirect_uri(s) (and if desired, post_logout_redirect_uri(s)).
For testing purpose, HTTP Basic authentication can also be used. However, it should be avoided for production applications.
API-key
API supports reading data using "API-key". This access mode intended to be used by a person for reading ad-hoc data and/or recurring API-calls such as dashboards, PowerQuery (Excel, PoweBI), etc.
Keys can be generated as described here: Power Query#3.-Credentials/Login A generated key will reflect the logged in user and the project
Remarks using API-key
- It only supports reading operations
- An API-key is valid for a single project. A user may generate multiple API-keys for accessing different project. Generating API-Key twice for the same project will result in same key.
- API-keys belong to a single user and are confidential, thus should not be shared
- API-key does not intended to be used for machine-to-machine communication and should not be used as such
Technical description
One should send API-key with each HTTP request as standard Authorization header with Reference scheme
Authorization: Reference <API-key>
Note that many clients does not allow setting Authorization headers (for example Excel or pasting URL into browser's address bar), but will prompt for inputting username and password when server sends "Unauthorized" respond. Such prompt will result sending request with Authorization header with Basic scheme. So as a fallback, the application also accepting API-key encoded as Authorization header with Basic scheme, where username is a constant apikey and password is the API-key. The wire format will thus look like the following:
Authorization: Basic base64urlencode(apikey:<API-key>)
This is just an illustration, we recommend using Reference scheme whenever possible. Using API-key encoded in Basic scheme is unnecessary if clients have full control over request headers.
Providing database and projectId
All API endpoints should provide database and project number as part of the URL path, for example https://api-host/api/database/projectId/resources
Queries
We model our query-syntax on the OData standard, but currently only support a small subset of it.
...