# Connected apps (OAuth) For software other Instasent customers will install: let each of them authorize your application against their own project with OAuth 2.1, and never handle their credentials. Full Product API access, scoped to what they grant. **Language:** en **Audience:** developer **Search keywords:** oauth, connected app, connected apps, authorization, oauth 2.1, dcr, dynamic client registration, scopes, permissions, verified app, third party app, authenticate as app, api key, api token, isv, build an integration, install my app, multi tenant **Related pages:** /developers/product-api/authentication, /platform/en/developers-and-apps/connect-your-ai **Docs index (every page):** https://docs.instasent.com/llms.txt **This zone's index:** https://docs.instasent.com/developers/product-api/llms-full.txt **This page:** https://docs.instasent.com/developers/product-api/connected-apps-and-oauth/ (HTML) · https://docs.instasent.com/developers/product-api/connected-apps-and-oauth.md (Markdown) ## Who this is for You are building software that **other Instasent customers will install** — an integration, a product, an app in someone's stack. Each of them authorizes it against their own project, you never see their credentials, and any of them can cut you off from their dashboard without involving you. If that isn't you, you probably want the other door: - [Integrating your own account](/developers/product-api/authentication) - Your backend calling Instasent for your own organization, with no other customers involved. Create an API token and carry it — none of the OAuth machinery below applies. - [Connecting an assistant you use](/platform/en/developers-and-apps/connect-your-ai) - Not building anything, just want your own AI working with your project? That is the MCP server, and it needs no code at all. > **Note**: For the dashboard-side view — how a customer approves a connection and revokes > it — see [Developers & Apps](/platform/en/developers-and-apps) in the Platform > zone. The full OAuth surface (`/oauth/register`, `/oauth/token` and the > discovery documents) is in the > [API reference](/developers/product-api/reference). A **connected app** is the second way to authenticate the Product API (the other is [API tokens](/developers/product-api/authentication)). Instead of a customer pasting a long-lived token into your software, **they authorize your application against their project with OAuth 2.1** — and can revoke it at any time from the dashboard. Once authorized, a connected app calls the **full Product API** with the scopes the customer granted: audience, events, segments, campaigns, automations, direct SMS and contact ingestion — the same surface a token of equivalent scope reaches. This is the path for building an integration or product on top of Instasent that many customers install. > **Warning**: A connected app (OAuth) is **not** the same as the > [MCP server](/platform/en/developers-and-apps/connect-your-ai). A connected app > authenticates against the **full** Product API; MCP is a separate, > agent-oriented surface with a curated tool set that reads and drafts but > never sends. They both use OAuth, but they grant very different access. ## Registering your application You don't pre-arrange anything with us. **Dynamic Client Registration** (RFC 7591) creates the client itself: `POST /oauth/register` with your application's name and redirect URIs returns the `client_id` you then drive the authorization code flow with. There is no client secret — every client registered this way is a **public client** and proves itself with PKCE alone. > **Warning**: **Registration is rate-limited, and it is meant to be a one-off.** Register > once and reuse the `client_id` — don't register on every run, from every > developer's machine, or as part of your test suite. If a registration is > refused unexpectedly, that is the most likely reason: wait a while and retry > before assuming your request is malformed. A client registered this way is **unverified**. It works, and the consent screen presents it as an application Instasent hasn't reviewed — which the user has to acknowledge explicitly before continuing. Note that a project can also be set to accept only verified applications, in which case an unverified client cannot be authorized on it at all. Rejections come back in the RFC 7591 shape — `{"error", "error_description"}`, not the platform's generic error envelope — with `invalid_client_metadata`, `invalid_redirect_uri` or `client_name_not_allowed`. ## The rest of the surface The full contract — every parameter, every error code, the discovery documents and the scope list — is in the [API reference](/developers/product-api/reference): - `GET /oauth/authorize` — start the flow in the browser; redirects to consent. - `POST /oauth/register` — dynamic client registration. - `POST /oauth/token` — code exchange and refresh. - `/.well-known/oauth-protected-resource`, `/.well-known/oauth-authorization-server` and `/.well-known/openid-configuration` — discovery. Read the endpoints from these rather than hard-coding them. > **Note**: **`/oauth/authorize` lives on this host, but nothing is decided there.** Open > it in the user's browser with your PKCE parameters and it answers `302`, > forwarding them to the dashboard — which is what authenticates the user and > renders the consent screen. It exists here so the whole authorization server > is advertised on **one origin**: `issuer`, `authorization_endpoint`, > `token_endpoint` and `registration_endpoint` all share the API host, which is > what strict clients require. ## Related - [API tokens](/developers/product-api/authentication) — the other authentication method, for your own server-side integrations. - [AI agents](/platform/en/developers-and-apps/connect-your-ai) — Platform overview for dashboard users. --- This is one page of the Instasent documentation. For the complete machine-readable index of every guide and API reference, fetch https://docs.instasent.com/llms.txt — start there for full context.