Partner OAuth Integration
Beta. OAuth mode is rolling out gradually. Contact us to get your app registered.
If you plan to integrate ofox into your product, users can click an OAuth button to sign in and authorize on ofox, then return to your app. New users who register this way are automatically attributed to your partner channel — exactly as if they had signed up through your referral link.
How to get started
You can apply while your app is still in development. A finished product is not required. OAuth integration is currently in Beta, and our team needs to confirm the registration details.
- If you have not applied to the partner program, start on the Partner page . Existing applicants and activated partners do not need to apply again.
- Send the details below to hi@ofox.ai, or reply to your existing support email thread.
- Once we confirm your app details, callback URLs and required permissions, we register the OAuth app, link your partner channel and provide the corresponding integration configuration.
- Implement the OAuth 2.1 flow and verify authorization, the return to your app and model calls.
Channel attribution does not require extra referral parameters: we configure it during registration. You still need to implement the OAuth callback, permissions and authorization flow using the integration configuration.
What to provide for app registration
| Information | What to include |
|---|---|
| App name and purpose | A working name is fine. Describe its main features, intended users and how it will use ofox model services |
| App type | Website, desktop app, mobile app, browser extension or CLI; specify whether you have your own backend |
| OAuth callback URLs (Redirect URIs) | Full URLs where users return after authorization, listed separately for testing and production. URLs must be confirmed before registration; if undecided, describe your technical setup first |
| Partner details | The email used for your partner application, plus your referral link or code. Do not resend details already supplied in the same thread |
| Required features | For example, calling models, displaying balance or usage, reading organization information or staying signed in. Describe your needs rather than requesting every permission |
| Product link and logo (can follow later) | Include a website, repository, demo or screenshots if available. For an unreleased product, a short description is enough to start; the logo can follow later |
Callback URLs must exactly match the registered values. Wildcards are not supported; the scheme, host, port, path and trailing / must match. HTTPS is recommended for production websites. For desktop, mobile or local development, describe your callback method when applying.
You do not need to submit full source code or a finished product to start an integration inquiry. Do not send passwords, API keys, client secrets or access tokens in your application email.
Copy this template and mark any undecided items as “to be confirmed”:
App name:
Purpose / intended users:
App type / backend availability:
Test callback URLs:
Production callback URLs:
Partner application email:
Partner referral link or code:
Required features:
Product link / description (if available):
Logo (if available):Before integrating
- Client type: An app with a backend that can protect a secret needs different configuration from an app running directly in a browser, desktop or mobile device. Describe your architecture; never embed a client secret in frontend code or a distributed application package.
- Permissions: Request only what your product needs. Model calls require
llm.invoke; confirm other permissions according to your features and check the permissions actually granted. - Troubleshooting: Use the configuration supplied after registration. If you encounter a problem, provide reproduction steps, a sanitized error message and the time it occurred, without tokens or secrets.
What gets attributed
New registrations only. When a user who has no ofox account clicks your OAuth button, they are taken to the ofox sign-in page, switch to sign-up, and complete registration. At that moment the binding to your channel is created. From then on, their top-ups and usage flow through the normal partner commission settlement.
Users who already have an ofox account keep their existing attribution. Authorizing your app does not change it — not even if they have never been attributed to any partner. This applies both to users already bound to another partner and to users with no binding at all.
This is deliberate: a referral binding is permanent and exclusive for the lifetime of the account. Allowing re-binding would let one partner take over users another partner brought in.
First-call scope
The access token you receive right after sign-up may not include llm.invoke yet.
llm.invoke is only granted to users whose email address is verified. Whether that is already true at the moment of sign-up depends on how the user registered:
| Sign-up method | Email verified on completion | llm.invoke in the first token |
|---|---|---|
| Passwordless link | Yes — clicking the link is the verification | Granted |
| Email + password | Not yet | Dropped until verified |
When a scope is dropped, the token request still succeeds — the scope field in the response lists what was actually granted, per RFC 6749 §3.3. Read that field instead of assuming you got everything you asked for. Calling the LLM API without llm.invoke returns 403 insufficient_scope.
Once the user verifies their email, request a new token (or refresh) and llm.invoke will be included.
Commission
Attributed users are settled under the standard tiered partner commission (up to 9%), based on actual API usage. Payouts start at $50 and are settled monthly. See the Partner page for current terms.