---
title: "OAuth Client ID Metadata Document Support"
slug: oauth-client-id-metadata-document-support
description: "OAuth clients can now identify themselves with a hosted metadata document instead of registering with Resend at runtime."
created_at: "2026-08-21"
updated_at: "2026-08-21"
image: https://cdn.resend.com/posts/oauth-client-id-metadata-document-support.jpg
humans: ["felipe-freitag"]
---

Today, we're announcing support for OAuth Client ID Metadata Documents (CIMD).

With CIMD, a client hosts a JSON document describing itself. Resend fetches that document during authorization, so the client can use the document's HTTPS URL as its `client_id` without registering separately at runtime.

This new registration method:

- gives clients a stable identity across installations
- reduces per-install registration and cleanup
- supports the [new MCP specification](/changelog/resend-mcp-supports-the-new-2026-07-28-spec)

The new support for CIMD simplifies [**building OAuth clients for Resend**](/docs/guides/building-a-resend-oauth-client#client-id-metadata-documents).

## Backwards compatibility

When we [added OAuth support](/changelog/oauth-support), we added support for Dynamic Client Registration (DCR). DCR registers a client with the authorization server and issues a client ID for that registration.

With CIMD, the client hosts a metadata document at an HTTPS URL and uses that URL as its `client_id`. Resend fetches and validates the document during authorization. This gives the client one stable identity across installations without requiring a separate registration for each install.

Resend's OAuth discovery metadata now advertises CIMD support:

```json
{
  "client_id_metadata_document_supported": true
}
```

Clients that support CIMD can use it automatically. Clients that support only DCR will continue to work, as this change is backwards compatible.

## What you can build with it

- **Remote MCP servers**: use one stable `client_id` for the client application across users and installations, instead of creating a new registration every time someone connects.
- **Distributed CLIs and desktop apps**: have every copy of your tool use the same hosted metadata document instead of registering on first run.
- **Public OAuth clients**: skip `/oauth/register` and use the document's URL as your `client_id`.

## How it works

First, host a JSON document describing your client. The document's `client_id` must be the same URL where the document is hosted:

```json
{
  "client_id": "https://example.com/oauth/client.json",
  "client_name": "Example App",
  "client_uri": "https://example.com",
  "redirect_uris": [
    "https://example.com/oauth/callback"
  ],
  "grant_types": [
    "authorization_code",
    "refresh_token"
  ],
  "response_types": [
    "code"
  ],
  "token_endpoint_auth_method": "none",
  "scope": "emails:send"
}
```

The document must be publicly accessible over HTTPS and served as JSON. Because the document is publicly readable, CIMD clients are public clients and must not include a client secret.

Next, pass the document's URL as the `client_id` in the authorization request instead of using a client ID returned by `/oauth/register`:

```
GET https://api.resend.com/oauth/authorize?client_id=https%3A%2F%2Fexample.com%2Foauth%2Fclient.json&response_type=code&redirect_uri=https%3A%2F%2Fexample.com%2Foauth%2Fcallback&scope=emails%3Asend&state=STATE_VALUE&code_challenge=CODE_CHALLENGE_VALUE&code_challenge_method=S256
```

Resend fetches the document, validates the client metadata, and runs the rest of the authorization code and PKCE flow as it does for registered clients.

Open the authorization URL in the user's browser like any other authorization request. CIMD requires no registration request, and the client uses the same document URL as its `client_id` when calling `/oauth/token` and `/oauth/revoke`.

The authorization server validates the requested redirect URI against the redirect URIs in the metadata document. The value must match exactly.

## Unverified clients

CIMD establishes control of the domain that hosts the metadata document, but the metadata itself is self-declared. Resend therefore treats CIMD clients as unverified.

The consent screen leads with the host that publishes the document.  The self-declared application name appears below it in quotation marks:

```
example.com wants access

"Example App" is an app on your device. Pick which team it can access.
```

This helps users distinguish between the domain hosting the client metadata and the name provided by the client itself.

## Conclusion

CIMD gives public OAuth clients a stable identity without requiring a separate registration for every installation. It is especially useful for distributed applications, CLIs, desktop apps, and remote MCP clients.

DCR continues to work for clients that depend on it. Check [Building an OAuth client for Resend](/docs/guides/building-a-resend-oauth-client#client-id-metadata-documents) for the full field reference, caching rules, and redirect URI requirements.