Announcing Appwrite Apps: Create apps that build on your users' Appwrite projects_

Plenty of useful tools live on top of other people's Appwrite projects: usage dashboards, deployment pipelines, migration helpers, AI agents that manage a backend on command. Until now, every one of them started the same way, by asking the user to create an API key and paste it in.

That handshake has always been the weak point. The key carries whatever scopes and expiry the user picked at creation, works for a single project, and once pasted, lives entirely outside their control. For agencies and partners who build tools for other Appwrite developers, it also makes onboarding feel heavier than it should.

Today, we are announcing Appwrite Apps: register an app in your organization, and it can serve every Appwrite developer. Behind it, Appwrite is now an OAuth 2.1 and OpenID Connect provider: your app sends any Appwrite user to a consent screen, asks for access to the projects and organizations they choose, and receives tokens that call their project APIs directly. New documentation for building apps ships with it, written for the partners and teams that build on top of Appwrite.

What this gives you

Sign in with Appwrite is the authorization code flow from OAuth 2.1, served by Appwrite, with the same consent experience users know from "Sign in with Google".

• A consent screen instead of a pasted key. The user sees your app's name and logo, reviews each requested permission in plain language, and picks which projects and organizations the grant covers.
• Scoped access across every product. Project scopes such as project:databases.read map to the same permissions API keys use, one .read and one .write scope per resource, and organization scopes cover members, projects, domains, and keys.
• One token for every region. The access token works on any granted project in any region. Your app reads each project's endpoint from the listing API and never maps regions itself.
• Standards all the way down. Access tokens are at+jwt JWTs signed with RS256, refresh tokens rotate on every use, revocation follows RFC 7009, and any OAuth2 or OIDC library works against the discovery document without Appwrite-specific code.
• A device flow for CLIs and TVs. Input-constrained clients sign in with a short user code approved from the user's phone or laptop, following RFC 8628.
• Revocation the user controls. Every authorization appears on the user's account applications page, where they can revoke a token family or the whole app at any time.

Register your app in the Console

Registration happens in your organization's Marketplace tab. Click Add app, then give it a name, a slug, a category, and a short description. The slug becomes your client ID.

The new app opens on its settings pages. On OAuth client, keep the client type as Confidential if your app has a server that can hold a secret, and add your callback URL to Redirect URIs. After the user approves, Appwrite only ever redirects to a URL on this list.

Last, on OAuth secrets, select Create secret and copy the value; it is shown once. Store the client ID and the secret in your server's environment. Mobile apps, desktop apps, and SPAs cannot keep a secret, so they register as public clients and prove themselves with PKCE instead.

The registration docs cover the remaining pages, including the logo, tagline, and legal links that shape your consent screen listing.

Send a user through the consent flow

With credentials in place, your sign-in button redirects the user to the authorization endpoint. The query string carries the identity scopes plus any project scopes your app needs:

https://cloud.appwrite.io/v1/oauth2/console/authorize
  ?client_id=<CLIENT_ID>
  &redirect_uri=<REDIRECT_URI>
  &response_type=code
  &scope=openid profile email project:databases.read

Because the request carries a project scope, the consent screen asks the user which projects the grant covers. They can grant fewer projects than you asked for, or decline entirely.

On approval, the browser returns to your redirect URI with a single-use authorization code. Exchange it from your server within five minutes:

The response carries an access token, a refresh token, and an ID token, and echoes what the user actually granted:

{
  "access_token": "eyJ0eXAiOiJhdCtqd3QiLCJhbGciOiJSUzI1NiJ9...",
  "token_type": "Bearer",
  "expires_in": 28800,
  "refresh_token": "eyJhbGciOiJIUzI1NiJ9...",
  "scope": "openid profile email project:databases.read",
  "authorization_details": [{ "type": "project", "identifiers": ["*"] }],
  "id_token": "eyJhbGciOiJSUzI1NiJ9..."
}

Check authorization_details for the projects the user selected; they may cover less than you asked for. Access tokens last 8 hours for confidential clients, and refresh tokens rotate on every use, so store the new one as soon as each exchange returns. The tokens docs cover lifetimes, rotation, and revocation in detail.

Call the projects the user granted

Every Sign in with Appwrite token can list the projects and organizations it was granted:

Each entry carries the project's $id, region, and endpoint, which is everything your app needs to call it. Point a client at a granted project's endpoint, keep the same bearer token, and call the APIs your scopes allow:

A call outside the granted scopes or projects fails with a 401 error of type general_unauthorized_scope, so the token can never do more than the user approved.

Sign in from CLIs and devices

Some clients cannot run a redirect flow: a TV has no browser to send the user back to, and a CLI has no redirect URI. For these, Sign in with Appwrite supports the device authorization grant. Your app requests a device code, shows the user a short code and a verification URL, and polls the token endpoint while the user approves from their phone or laptop.

The response also includes a verification_uri_complete variant with the code in the URL, which is what you encode into a QR code so the user skips typing. The flow is off by default; enable it with the device flow toggle on your app's OAuth client page. The device flow docs walk through the whole exchange.

Users stay in control

Consent is not a one-time gate. Every approval appears on the user's account applications page, where they see the scopes your app holds and the tokens issued under it, and can revoke a single token family or the whole authorization at any time.

Refresh tokens are single-use, and a token that gets used twice looks like theft, so Appwrite responds by invalidating the entire token family. When a user disconnects your app on your side, return the favor and revoke the tokens you hold at the revocation endpoint. The consent docs cover partial grants, silent re-authorization for returning users, and the prompt parameter.

Sign users in through Appwrite Auth

If your product itself runs on an Appwrite project, you do not need to handle the flow by hand. Appwrite Auth ships an Appwrite OAuth2 provider. In your project, open Auth, then Social providers, and select Appwrite. Quick setup creates or picks an organization app, registers the callback URI, and fills in the client ID and secret for you.

Then sign users in with the same call you would use for GitHub or Google, adding the project scopes your app needs:

After sign-in, the issued tokens live on the user's identity, and your backend reads them from there to call the granted projects.

Get started building apps

Appwrite Apps are available on Appwrite Cloud today. Register an app in your organization's Marketplace tab and run the full flow with the quick start, from consent screen to your first authorized API call.

More resources