OAuth Readiness

How guides are made

The hard part of an integration is rarely the OAuth code. It’s the provider’s approval process: whether you can launch next week or are stuck in review for two months. These guides answer that question first, then show the steps.

Two ways a guide is written

Library guides

One Claude Code research agent per app reads the provider’s docs, policies and developer reports, then writes a structured guide. Each agent works only on its own app and must copy every quote verbatim from a page it fetched. For some apps we also created the OAuth app by hand and recorded what actually happened.

Live guides

When you submit an app that isn’t in the library, a research agent runs on the spot:

  1. Gemini searches the web (Google Search grounding) and writes research notes.
  2. Code fetches the pages it used and keeps the passages about OAuth, review and verification.
  3. Gemini turns the notes into the guide format, quoting only from those passages.
  4. Code checks every quote against its page, sets each source’s evidence level from its domain, and checks Composio’s managed-app list.
  5. Code computes the difficulty tier from the facts.

Live guides take about a minute and are shallower than library guides. Their evidence section shows exactly how much held up.

What the AI decides, and what it doesn’t

The AI gathers facts and writes the explanations. It doesn’t pick the difficulty. The tier comes from seven yes, no or unknown facts by a fixed rule:

  • Partner, paid or sales-only access, or no self-serve credentials: tier 5.
  • Otherwise, a security assessment, business verification or fees: tier 4.
  • Otherwise, provider review before outside users can connect: tier 3.
  • Otherwise, limits until reviewed (user caps, short-lived tokens, warning screens): tier 2.
  • Otherwise: tier 1.

An unknown fact never raises the tier on its own, but it forces confidence to low and is listed on the guide, so you can see the tier might be higher.

Evidence levels

Tested by us
We created the OAuth app ourselves and recorded what happened, including where it differed from the docs.
Provider docs
The provider's own documentation or policy pages. Strongest written evidence.
Secondary source
Integration platforms and vendor guides writing about the provider. Useful, sometimes out of date.
Community report
Forums, Stack Overflow, Reddit. Good for real wait times and rejection stories, but anecdotal.
Inferred
Reasoned from other facts, with nothing stating it directly.

Every quote is checked by code against the live page. If a quote from the provider’s docs can’t be found, that source counts one level lower when we work out confidence.

Agent steps and your steps

A step is marked Agent when an AI agent could do it or draft it without your identity or legal authority: checking requirements, filling in redirect URIs and scopes, drafting a scope justification. It’s marked You when it needs your account, your agreement to terms, identity or business verification, payment, 2FA, or a recording of your real product.

Limits

  • Provider rules change. Every guide and source is dated, and nothing re-checks guides automatically yet.
  • Some docs only render with JavaScript, so their quotes can’t be checked automatically and are marked as such.
  • Wait times are mostly self-reported by developers. We show ranges, never a single promise.
  • Live guides run on a free model tier, so they can be rate-limited.