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.
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:
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 useNot building anything, just want your own AI working with your project? That is the MCP server, and it needs no code at all.
A connected app is the second way to authenticate the Product API (the other is API tokens). 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.
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.
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:
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-serverand/.well-known/openid-configuration— discovery. Read the endpoints from these rather than hard-coding them.
Related
- API tokens — the other authentication method, for your own server-side integrations.
- AI agents — Platform overview for dashboard users.