OAuth clients can now identify themselves with a hosted metadata document instead of registering with Resend at runtime.
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:
The new support for CIMD simplifies building OAuth clients for Resend.
When we added 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:
{"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.
client_id for the client application across users and installations, instead of creating a new registration every time someone connects./oauth/register and use the document's URL as your client_id.First, host a JSON document describing your client. The document's client_id must be the same URL where the document is hosted:
{"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.
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.
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 for the full field reference, caching rules, and redirect URI requirements.