Sign in with ChatGPT for developers: the OAuth flow, plan usage, and what it means for your API bill

Sign in with ChatGPT is OpenAI’s OAuth 2.0 and OpenID Connect login, available to ChatGPT users globally. Your app gets a stable account ID plus the person’s name, email address and profile picture. Since DevDay on September 29, 2026, Plus and Pro users can also let participating apps run AI requests on their ChatGPT plan instead of your API key, under a weekly cap they set per app. Your app never receives their conversations, memories or an API key.

The second part touches your bill. This guide covers the flow, how plan usage looks to the user, who can integrate today, when a user’s plan should replace your key, and how to test sign-in and its failure paths in Apidog. For the rest of the event, see the DevDay 2026 roundup; if identity versus authorization is fuzzy, read OAuth vs OpenID first.

Sign in with ChatGPT at a glance

Sources: the Sign in with ChatGPT docs, the token reference, and OpenAI’s help article on using your ChatGPT plan in other apps.

What your app receives, and what it doesn’t

Identity is the default. A client that requests openid profile email gets an ID token. Per the website guide, profile covers available claims such as name and profile picture, and email covers email and email-verification claims. Identity scopes don’t grant access to ChatGPT conversations or OpenAI API resources.

Key the account on the verified sub plus issuer and client ID, not the email. OpenAI warns that an email match alone isn’t proof of ownership, so ask existing users to confirm a link.

Plan usage is a separate grant. If the user approves the extra scopes, the token response adds an access token for eligible Responses API requests. Identity-only clients shouldn’t require an access_token at all: the id_token is the only required artifact.

How the OAuth flow works

The website flow is the standard Authorization Code grant with PKCE plus OIDC. Load endpoints from https://auth.openai.com/.well-known/openid-configuration. The docs list these production values:

Issuer:                 https://auth.openai.com
Authorization endpoint: https://auth.openai.com/api/accounts/authorize
Token endpoint:         https://auth.openai.com/api/accounts/oauth/token
JWKS URI:               https://auth.openai.com/.well-known/jwks.json

1. Your backend generates a fresh state, a PKCE verifier with an S256 challenge, and a nonce.
2. It redirects the browser to the authorization endpoint with your client ID, exact redirect URI and scopes.
3. The user consents, and OpenAI returns a code to your callback.
4. Your backend checks state, exchanges the code, and verifies the ID token’s signature, issuer, audience, expiration and nonce.
5. It finds, creates or links the local account and issues its own session.

Public clients send no secret. A confidential client using client_secret_basic sends its secret only in the HTTP Basic header.

Open-source tools register differently. The open-source sign-in guide starts with client_id=dynamic_agent_client, an agent_name_hint set to your app’s name, and a persistent ext_agent_host_id per host. The callback returns an issued client ID (such as oaiapp_...) to save and reuse; the redirect is a 127.0.0.1 loopback URI, and no client secret is involved.

How plan usage works for the user

What your users see, and what your support docs should explain:

• Eligible requests count against the plan. They draw on the ChatGPT Work and Codex usage in the user’s Plus or Pro plan.
• Each app gets a weekly cap. The user sets it as a percentage of overall weekly usage (the docs’ settings example runs from 10% to 100%). It’s a ceiling, not a reserved pool, so heavy use elsewhere can exhaust the plan first.
• Credits are opt-in. Continuing on credits after limits is off by default and requires the app’s cap at 100%.
• Plus has a shared five-hour limit. Per the accounts and sessions page, it spans every app using the plan. It doesn’t apply to Pro.
• Disconnecting stops future use. It doesn’t reverse usage already consumed, and OpenAI doesn’t notify your app; you find out when a request or refresh fails.

Users manage all of this under ChatGPT Settings, Usage (chatgpt.com/settings/usage), and OpenAI’s UI guidelines ask you to link there with Manage usage.

Who’s in at launch, and how you get a client ID

OpenAI’s DevDay recap names 16 plan-usage partners, including Cognition’s Devin, Notion, Vercel, T3, OpenClaw and Dactyl. The New Stack lists Amp, Warp, Kilo Code and OpenCode among the others, with Lovable marked as coming soon. If you run OpenClaw, it’s on both lists.

Sam Altman’s pitch on stage, as The New Stack reported it: “now you don’t have to cover their token costs to get them going.”

How you get in depends on what you ship:

• Commercial or hosted apps: sign-in is a limited trial. You request a client ID by joining the waitlist through OpenAI’s interest form, whether you want identity alone or plan usage too (the docs’ URLs call plan usage “token sharing”).
• Open-source and locally hosted tools: plan usage is open to all open-source partners through the self-serve flow above.

What changes for your API bill

Today you pay per token and recover it through pricing. Plan usage moves the model cost onto the user’s subscription, so your margin stops depending on how heavily they use AI. The tradeoff is control.

The restrictions come from the preview limitations page: features that need stored conversation state or hosted tools won’t run on a user’s plan today.

A sensible default is hybrid: plan usage for interactive work by Plus and Pro users, your key for everyone else and for background jobs, CI and scheduled agents. When the cap hits, show Manage usage and offer your own credits as a secondary option. The API key vs OAuth comparison covers the general tradeoff, and OAuth for AI agents covers acting on a user’s behalf safely.

How to test the sign-in flow and failure paths in Apidog

Apidog doesn’t sign anyone in with ChatGPT. It exercises your OAuth setup, token calls and error handling. Download Apidog and create an environment.

1. Store the client as variables. Add SIWC_CLIENT_ID, SIWC_REDIRECT_URI, and for a confidential client SIWC_CLIENT_SECRET as a sensitive value, plus ACCESS_TOKEN for plan usage. Reference them as {{SIWC_CLIENT_ID}} so no secret lives in a saved request.

2. Run the Authorization Code flow. In the Auth tab, pick OAuth 2.0 with Authorization Code with PKCE, enter the endpoints above, set scope to openid profile email, and use a callback URL registered for your client. The Apidog OAuth 2.0 guide walks through each field.

3. Assert on the ID token you got. Save the token exchange as its own POST to the token endpoint (code, verifier, redirect URI, client ID) and add a post-processor to it. Signature and nonce checks still belong in your backend.

const body = pm.response.json();
pm.test("token exchange returned an ID token", () => {
  pm.expect(pm.response.code).to.eql(200);
  pm.expect(body.id_token).to.be.a("string");
});

const decode = require("atob");
const part = body.id_token.split(".")[1].replace(/-/g, "+").replace(/_/g, "/");
const claims = JSON.parse(decode(part + "=".repeat((4 - (part.length % 4)) % 4)));

pm.test("ID token claims match this client", () => {
  pm.expect(claims.iss).to.eql("https://auth.openai.com");
  pm.expect(claims.aud).to.include(pm.environment.get("SIWC_CLIENT_ID"));
  pm.expect(claims.sub).to.be.a("string").and.not.empty;
  pm.expect(claims.exp * 1000).to.be.above(Date.now());
});

Log name, email and picture rather than asserting them, since they’re returned when available. For plan usage, assert that body.scope contains chatgpt.tokens.use.direct.

4. Mock the failure paths. A real Plus account is a poor fixture, so return these from an Apidog mock server:

• Plan usage declined: a token response whose scope lacks chatgpt.tokens.use.direct. Your app should keep the sign-in and offer to enable plan usage or use another billing path.
• Cap reached: 429 with error.code subscription_sharing_usage_limit_exceeded, plus the same code in a response.failed stream event. Assert that your app pauses plan requests.
• Not eligible: 403 subscription_sharing_user_not_eligible. Don’t retry or loop through OAuth.
• Disconnected: a refresh returning invalid_grant, or 401 subscription_sharing_invalid_user. Clear tokens and ask for sign-in again.

Chain the cases into a test scenario and run it in CI with the Apidog CLI. The errors and recovery page lists the full set.

5. Check the live call. With a real plan token, send the docs’ streaming request (in Apidog, as Bearer {{ACCESS_TOKEN}}) and confirm the stream ends in response.completed, the only success signal:

curl --no-buffer https://api.openai.com/v1/responses \
  -H "Authorization: Bearer ${ACCESS_TOKEN}" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gpt-6.1-sol",
    "input": [{"role": "user", "content": "Say exactly: Hello, world!"}],
    "store": false,
    "stream": true
  }'

FAQ

Can Free users sign in with ChatGPT? Sign-in is available to ChatGPT users globally. Using the plan inside another app requires Plus or Pro.

Does my app get the user’s OpenAI API key? No. You get an ID token and, with plan usage, an OAuth access token for eligible Responses API requests.

What happens when a user hits their cap? Requests fail with subscription_sharing_usage_limit_exceeded: an HTTP 429, or a response.failed event after streaming starts. Pause and link to Manage usage.

Can a Plus user run GPT-6.1 Sol through a partner app? The docs’ example uses gpt-6.1-sol with a plan token, but list the account’s models with that token before offering one. More in is GPT-6.1 Sol free.

Next step

If you run a commercial app, join the waitlist now, and build your cap and disconnect handling against mocks while you wait. Treat plan usage as an option beside your own API billing, not a replacement. Save the token assertions and failure scenario in Apidog, so the day your client ID arrives, the only new variable is the real token.