Before your first call you need an app registered with Davi and a client that can complete the flows the API requires.
Register an app
Apps are registered per organization, in the dashboard under Developer → Apps. There is no public endpoint that creates a client.
You set four things:
| Setting | What it decides |
|---|---|
| Client type | Confidential or public (see below) |
| Redirect URIs | Where Davi may return the user after they authorize |
| Grant types | Which flows the app may use |
| Scopes | What the app may ask a user to consent to |
You receive a Client ID and, for a confidential app, a Client Secret that is shown once. Store the secret like any other credential. If you lose it, rotate it; do not register a second app.
Redirect URIs are matched exactly. A URI that differs by a trailing slash, a
port, or http versus https is a different URI, and the authorization request
is refused rather than redirected.
Scopes are set at registration, not at request time. Asking for a scope the app was not registered with fails at authorization; it does not return a token with fewer scopes. Register every scope the integration will need, including ones for features you have not built yet.
Choose a client type
| Type | For | Authenticates with |
|---|---|---|
| Confidential | A server-side application that can keep a secret | client_secret_basic or client_secret_post, and may use client_credentials |
| Public | An SPA, mobile or desktop app, which cannot keep a secret | PKCE, with token endpoint auth method none |
What decides the type is whether the secret can be kept from the user, not whether the app has a backend. A single-page app with an API behind it is public if the secret would be shipped to the browser.
What your client must support
- PKCE with
S256, for every client, public and confidential. Without a code verifier and an S256 challenge, a client cannot complete the authorization code flow. - HTTPS redirect URIs, except for loopback during local development.
- Storing a rotating refresh token. Every refresh returns a new refresh token and retires the one you sent. A client that keeps the original logs the user out at its next use, and replaying a used refresh token revokes the whole session.
- Serialized refreshes. If your client can refresh from more than one place at once, the concurrent requests race and the losing request's token counts as a replay.
Next
- Quickstart: from a registered app to an authenticated request.
- Authentication Model: grants, tokens and how they fit together.