Evidence and method
What a guide is for. An agent that acts for users in another app needs a provider OAuth app: a registered client (id, secret, redirect URIs, consent screen) that the provider trusts. Creating it is usually quick; getting it approved for users outside your own account is where the weeks go. Managed-OAuth platforms hide this by sharing one pre-approved app, but they don't cover every provider, and anyone who needs their own brand on the consent screen, their own rate limits or their own scopes ends up registering their own app.
How each claim is marked. tested = we did it: set it up in a real console, or the agent probed the provider's live OAuth endpoints. sourced = an official page says so, quoted in the sources list. inferred = third-party reports or reasoning; treat as uncertain. Review wait times are almost never documented, so they are usually inferred.
tested claims
39
sourced claims
181
inferred claims
18
Spot checks across the library
73 checks: 42 confirmed, 23 corrected, 8 could not be verified.
| App | Claim | Result |
|---|---|---|
| GitHub (GitHub App / OAuth App) | OAuth Apps allow only one callback URL and issue non-expiring tokens Fetched 'Creating an OAuth app' · The form now accepts up to 10 callback URLs and has an 'Expire user access tokens' checkbox enabled by default. | corrected |
| GitHub (GitHub App / OAuth App) | Installing a GitHub App in an org needs org owner approval Fetched 'Installing a GitHub App from a third party' and 'Requesting a GitHub App from your organization owner' · Owners install directly; repo admins can install on their own repos when the app requests no org permissions; only other members need to request. OAuth app access restrictions (on by default in new orgs) do not apply to GitHub Apps. | corrected |
| GitHub (GitHub App / OAuth App) | Only org owners install on an org; repo admins only when no organization permissions are requested Independent check: fetched docs.github.com 'Installing a GitHub App from a third party' on 2026-10-30 · Repo admins are also blocked if the app requests the 'Repository administration' permission, and owners can disable repo-admin installs. Blocker and launch step updated. | corrected |
| Google (Gmail API) | Common claim: sensitive-scope review takes 3-5 business days Google's sensitive-scope page (s3) · Google now says 'up to 10 days'. Brand verification alone is minutes if automated, 2-3 business days if manual (s16). | corrected |
| Google (Gmail API) | Common claim: CASA has a free Tier 2 self-scan and Tier 3 lab audits Google Security Assessment help (s6), TAC price page (s7), 2026 community notes (s12) · Google now assigns AL1 or AL2 assurance levels. Community sources (2026) say the free self-scan is gone. Google's page does not mention price. | corrected |
| Google (Gmail API) | Brand verification takes about 2-3 business days Independent check: fetched Google's 'Brand verification' page on 2026-10-30 · Google: automated check typically a few minutes; 2-3 business days only when it falls to manual review. Verdict, step and blocker updated. | corrected |
| Google (Search Console, GA4, Business Profile) | Common claim: sensitive-scope review takes 3-5 business days Google's sensitive-scope verification page (s4) · Google now says up to 10 days, after brand verification (minutes if automated, 2-3 business days if manual) | corrected |
| Google (Search Console, GA4, Business Profile) | Consent screen is configured under 'APIs & Services > OAuth consent screen' Workspace guide (s6) and Iskaria's console session (s1) · It is now Google Auth Platform > Branding / Audience / Data Access / Clients | corrected |
| Google (Search Console, GA4, Business Profile) | Brand verification takes about 2-3 business days Independent check: fetched Google's 'Brand verification' page on 2026-10-30 · Automated check usually a few minutes; 2-3 business days only for manual review. reviewRequired updated. | corrected |
| HubSpot (CRM API) | You can choose between legacy public apps and Projects-based apps Search + legacy-public-app-creation-sunset changelog and legacy apps overview · Legacy public app creation disabled 26 May 2026 (new accounts) and 23 June 2026 (existing); current platform version is 2026.09, and 2025.2 must migrate by March 2027. | corrected |
| HubSpot (CRM API) | Sandbox/test installs count toward the 3-install listing minimum (appnigma blog) Fetched the official listing requirements page · Official: unique production accounts unaffiliated with your organisation, active in the past 30 days. | corrected |
| LinkedIn (Community Management API for Company Page posting) | Community Management Development tier is limited to 100 calls per app and 10 per member per day Fetched Community Management overview FAQ and Increasing Access table · Raised to 500 per app and 100 per member per 24 h. BATCH_GET is disallowed and webhooks are off. | corrected |
| LinkedIn (Community Management API for Company Page posting) | Company Page posting is part of the 'Marketing Developer Platform' Fetched Getting Access and Increasing Access · The docs now name separate vetted products (Advertising API, Community Management API) under the Marketing API program. Organic Page posting is the Community Management API. | corrected |
| LinkedIn (Community Management API for Company Page posting) | Refresh tokens are available to all apps Fetched 3-legged OAuth doc · Superseded by the independent check below: refresh tokens go to all approved Marketing Developer Platform apps (incl. Community Management). Access tokens last 60 days. | corrected |
| LinkedIn (Community Management API for Company Page posting) | Programmatic refresh tokens are partner-only / limited set of partners Independent check: fetched LinkedIn 'Refresh Tokens with OAuth 2.0' on Microsoft Learn on 2026-10-30 · Doc says all approved MDP partners get them (365-day refresh, 60-day access). An app approved for Community Management should receive them; self-serve apps do not. testMode and the token item updated. | corrected |
| Meta (Facebook Login for Business: Pages, Messenger, Instagram, WhatsApp Business) | Instagram posting/messaging always needs a Facebook Page link and instagram_content_publish / instagram_manage_messages Fetched Instagram Platform overview · True only for the Facebook Login path. Instagram API with Instagram Login uses instagram_business_content_publish / instagram_business_manage_messages and needs no linked Page. | corrected |
| Meta (Facebook Login for Business: Pages, Messenger, Instagram, WhatsApp Business) | A data deletion callback is mandatory Fetched data deletion callback doc · Either a callback URL or a deletion instructions URL satisfies the requirement. Iskaria's instructions page is enough. | corrected |
| Microsoft (Graph: Outlook mail and calendar) | Since 2020 the default tenant policy blocks user consent to apps from unverified publishers Fetched publisher-verification-overview and manage-app-consent-policies · The Nov 2020 block applies only where risk-based step-up consent is enabled. The current default (Microsoft-managed policy) instead blocks user consent to Mail.Read/Calendars.* regardless of publisher verification. | corrected |
| Microsoft (Graph: Outlook mail and calendar) | Mail.Read and Calendars.ReadWrite are user-consentable delegated permissions Graph permissions reference (Calendars.ReadWrite AdminConsentRequired = No) cross-checked against the Microsoft-managed exclusion list on Learn and a Nov 2025 community post · Technically user-consentable, but excluded from user consent by the default policy since the 2025 rollout. | corrected |
| Microsoft (Graph: Outlook mail and calendar) | Publisher verification needs an MPN ID Fetched publisher-verification-overview and mark-app-as-publisher-verified · MPN is now the Microsoft AI Cloud Partner Program; the field is the Partner One ID of the partner global account, location IDs are rejected. | corrected |
| Microsoft (Graph: Outlook mail and calendar) | Supported account type is called 'Accounts in any organizational directory' Fetched quickstart-register-app (ms.date 2026-05-14) · Labels are now 'Multiple Entra ID tenants' and 'Any Entra ID Tenant + Personal Microsoft accounts'; navigation is Entra ID > App registrations. | corrected |
| Slack (Slack app, OAuth v2) | conversations.history is Tier 3 Fetched the method reference · The reference still says Tier 3 (50+/min) and does not mention the non-Marketplace Tier 1 limit, so the reference page alone misleads agents that read history. | corrected |
| Slack (Slack app, OAuth v2) | Classic apps are being shut down Fetched the 2024 deprecation changelog · Legacy custom bots stopped 31 March 2025, but the classic-app shutdown (rescheduled several times through November 2026) is now paused. | corrected |
| GitHub (GitHub App / OAuth App) | GitHub App registration form field names (GitHub App name, Description, Homepage URL, Callback URL, Expire user authorization tokens, Request user authorization (OAuth) during installation, Enable Device Flow, Setup URL, Webhook Active/URL/secret, Permissions, Where can this GitHub App be installed?) Fetched the live 'Registering a GitHub App' doc · Also lists 'Redirect on update' and 'Subscribe to events', added to the steps. | confirmed |
| GitHub (GitHub App / OAuth App) | Installation token rate limit 5,000/h scaling to 12,500 (15,000 on Enterprise Cloud) Fetched REST rate-limit doc; the GitHub Apps rate-limit page gives no numbers and links there | confirmed |
| GitHub (GitHub App / OAuth App) | No review is needed to make a GitHub App public Read the registration and Marketplace docs for any approval step · No doc says so explicitly; none describes a review outside the optional Marketplace. | unverified |
| GitHub (GitHub App / OAuth App) | Installation tokens: 5,000 req/h, +50 per repo above 20, cap 12,500 (15,000 Enterprise Cloud); secondary 80 content-creating/min, 500/h, 900 REST points/min Independent check: fetched docs.github.com 'Rate limits for the REST API' on 2026-10-30 · All figures match; GitHub notes secondary limits can change without notice. | confirmed |
| GitHub (GitHub App / OAuth App) | OAuth endpoint behaviour (discovery metadata, PKCE, dynamic registration, unknown-client handling) Endpoint probe: node scripts/probe.ts on 2026-10-30 · github.com publishes no OAuth/OIDC discovery document (both 404), so no advertised PKCE methods and no registration_endpoint. The authorize endpoint with an unknown client_id answers 302 to /login rather than an error page. | confirmed |
| Google (Gmail API) | gmail.send is sensitive. gmail.compose, gmail.readonly, gmail.modify and gmail.metadata are restricted. gmail.labels is non-sensitive. Fetched the live Gmail API scopes page (s1) on 2026-10-30 · gmail.compose is often assumed to be a light scope. It is restricted. | confirmed |
| Google (Gmail API) | The consent screen setup now lives in 'Google Auth Platform' (Branding / Audience / Data Access / Clients) Workspace configure-consent guide (s10) plus Iskaria's own console session · Older guides still say 'APIs & Services > OAuth consent screen' | confirmed |
| Google (Gmail API) | Testing-mode refresh tokens expire after 7 days OAuth 2.0 overview (s5) and Iskaria's own weekly re-logins (s13) | confirmed |
| Google (Gmail API) | gmail.send sensitive; gmail.compose, readonly, modify, metadata restricted; gmail.labels non-sensitive Independent check: re-fetched developers.google.com/workspace/gmail/api/auth/scopes on 2026-10-30 · Also restricted: mail.google.com, gmail.insert, gmail.settings.basic, gmail.settings.sharing. | confirmed |
| Google (Gmail API) | Testing: max 100 test users, authorizations incl. refresh tokens expire 7 days after consent; unverified production cap 100 users lifetime, not resettable Independent check: fetched support.google.com/cloud/answer/15549945 on 2026-10-30 | confirmed |
| Google (Gmail API) | CASA is needed when restricted-scope data reaches or passes through your server, renewed every 12 months Independent check: fetched support.google.com/cloud/answer/13465431 and the restricted-scope verification page on 2026-10-30 · The help article says all restricted-scope apps are revalidated yearly without the server qualifier; the developer page keeps the 'from or through a third-party server' condition. CASA price not on any Google page (unverified). | confirmed |
| Google (Gmail API) | OAuth endpoint behaviour (discovery metadata, PKCE, dynamic registration, unknown-client handling) Endpoint probe: node scripts/probe.ts on 2026-10-30 · Discovery found at both oauth-authorization-server and openid-configuration; PKCE plain and S256; no dynamic client registration. Authorize with an unknown client redirected to Google's error page (invalid_request, missing scope) before checking the client. | confirmed |
| Google (Search Console, GA4, Business Profile) | Business Profile APIs need a separate access request. Quota is 0 QPM until approved, 300 QPM after. Fetched Google's Business Profile prerequisites page (s7), cross-checked with Unified.to (s8) and Iskaria's own experience (s1) | confirmed |
| Google (Search Console, GA4, Business Profile) | business.manage is a sensitive scope Unified.to (s8) vs the Google developer forum thread, 2026-07 to 2026-10 (s10) · Some 2026 consoles list it as non-sensitive while still blocking external users | unverified |
| Google (Search Console, GA4, Business Profile) | Testing-mode refresh tokens expire after 7 days OAuth 2.0 overview (s2) plus Iskaria's weekly re-logins (s1) | confirmed |
| Google (Search Console, GA4, Business Profile) | Business Profile API: quota 0 QPM until access approved; needs a profile verified and active 60+ days and a website Independent check: fetched developers.google.com/my-business/content/prereqs on 2026-10-30 · Approved projects show 300 QPM. Google gives no turnaround time. | confirmed |
| Google (Search Console, GA4, Business Profile) | webmasters.readonly and analytics.readonly are sensitive scopes Independent check: fetched developers.google.com/identity/protocols/oauth2/scopes (full page) and Search Console authorizing guide on 2026-10-30 · Neither public page labels sensitivity; only the Cloud console shows it. Still rests on the console warning Iskaria saw. | unverified |
| Google (Search Console, GA4, Business Profile) | OAuth endpoint behaviour (discovery metadata, PKCE, dynamic registration, unknown-client handling) Endpoint probe: node scripts/probe.ts on 2026-10-30 · Same Google authorization server as Gmail: PKCE plain and S256, no dynamic client registration; unknown client without scope -> 302 to signin/oauth/error (invalid_request). | confirmed |
| HubSpot (CRM API) | Unlisted apps are limited to 25 installs Fetched the HubSpot changelog post on install limits · Applies to Projects-based marketplace-distribution apps since 22 Sep 2025; private distribution is 10 accounts (100 for Solution Partners). | confirmed |
| HubSpot (CRM API) | Listing review takes about 10 business days Listing requirements page and certification requirements page · Initial review within 10 business days; full process up to 60 days. | confirmed |
| HubSpot (CRM API) | Certification needs 60 active installs and 6 months listed Fetched certification requirements page | confirmed |
| HubSpot (CRM API) | Marketplace-distribution apps on the new platform are capped at 25 installs until listed; private distribution 10 accounts (100 for Solution Partners) Independent check: re-fetched the HubSpot changelog 'New Marketplace Distribution App Install Limits' (s1) and the Authentication overview on 2026-10-30 · Applies from 22 Sep 2025 to apps created on or migrated to 2025.2+; legacy apps with >25 installs get the cap on migration. | confirmed |
| HubSpot (CRM API) | Listing needs 3 active installs from unaffiliated production accounts (30-day activity); first review within 10 business days Independent check: fetched the live App listing requirements page (s9) on 2026-10-30 · The 60-day figure is the maximum for the whole feedback process, counted from when feedback is shared, not from submission. | confirmed |
| HubSpot (CRM API) | Legacy public apps unsupported 15 Sep 2026 (enforcement Sep 2027); 2025.2 apps migrate to 2026.09 by March 2027; v1-v4 APIs lose certification after Sep 2027 Independent check: re-fetched the HubSpot changelog (s6) on 2026-10-30 | confirmed |
| HubSpot (CRM API) | OAuth endpoint behaviour (discovery metadata, PKCE, dynamic registration, unknown-client handling) Endpoint probe: node scripts/probe.ts on 2026-10-30 · HubSpot publishes RFC 8414 metadata: PKCE S256 only, code flow only, no dynamic client registration, no OIDC. Unknown client_id on /oauth/authorize returns HTTP 200 with the OAuth UI page (error rendered client-side). | confirmed |
| LinkedIn (Community Management API for Company Page posting) | w_member_social is self-serve but can't post as an organization Fetched Getting Access (open permissions) and a GitHub issue showing the HTTP 400 error | confirmed |
| LinkedIn (Community Management API for Company Page posting) | Community Management can only be requested on an app without other products Fetched Community Management overview FAQ #4 | confirmed |
| LinkedIn (Community Management API for Company Page posting) | Development tier review takes 10-14 business days Microsoft Q&A post (Aug 2026); no official page found | unverified |
| LinkedIn (Community Management API for Company Page posting) | Development tier: 500 calls/app and 100/member per 24 h, no BATCH_GET, social-action webhooks off, 12 months to finish; Standard tier is discretionary Independent check: fetched learn.microsoft.com/linkedin/marketing/increasing-access (version 2026-10) on 2026-10-30 | confirmed |
| LinkedIn (Community Management API for Company Page posting) | A rejected Development or Standard tier request cannot be re-applied on the same app; create a new app Independent check: fetched learn.microsoft.com/linkedin/marketing/community-management-app-review on 2026-10-30 · A rejected Standard request sends you back to a new app and a new Development tier form. | confirmed |
| LinkedIn (Community Management API for Company Page posting) | OAuth endpoint behaviour (discovery metadata, PKCE, dynamic registration, unknown-client handling) Endpoint probe: node scripts/probe.ts on 2026-10-30 · LinkedIn's OIDC discovery lives under /oauth (root .well-known paths 404) and lists only openid/profile/email; it advertises no PKCE methods and no dynamic registration. Unknown client_id on /oauth/v2/authorization returns HTTP 200 with an HTML page. | confirmed |
| Meta (Facebook Login for Business: Pages, Messenger, Instagram, WhatsApp Business) | Embedded Signup onboarding is capped at 10 new customers per 7 days until verification, then 200 Fetched Embedded Signup overview | confirmed |
| Meta (Facebook Login for Business: Pages, Messenger, Instagram, WhatsApp Business) | App Review returns a decision within about a week Fetched Meta submission guide; compared with 2026 developer reports · Official guide says within a week. 2026 third-party reports say ~20 days per cycle, so treat a week as the best case. | unverified |
| Meta (Facebook Login for Business: Pages, Messenger, Instagram, WhatsApp Business) | Development mode limits permission requests to role users Fetched App Modes and Access Levels docs | confirmed |
| Meta (Facebook Login for Business: Pages, Messenger, Instagram, WhatsApp Business) | Tech Provider Access Verification takes ~5 business days Meta forum threads quoting the dashboard (Sep-Oct 2026) · The dashboard states it, but several developers report 9+ business days. | unverified |
| Meta (Facebook Login for Business: Pages, Messenger, Instagram, WhatsApp Business) | Embedded Signup onboarding cap: 10 new business customers per rolling 7 days before Business Verification + App Review + Access Verification Independent check: re-fetched developers.facebook.com/docs/whatsapp/embedded-signup/ on 2026-10-30 · Added the raised limit (200 per rolling 7 days, automatic) to the blocker. | confirmed |
| Meta (Facebook Login for Business: Pages, Messenger, Instagram, WhatsApp Business) | App Review decision in about a week (Meta) vs ~20 days per cycle (developer reports) Independent check: re-fetched developers.facebook.com/docs/app-review/submission-guide/ on 2026-10-30 · Meta: 'you should receive a decision within a week'. The 20-day figure is third-party only. If Meta cannot access the app, the entire submission is rejected; otherwise permissions are judged one by one. | confirmed |
| Meta (Facebook Login for Business: Pages, Messenger, Instagram, WhatsApp Business) | OAuth endpoint behaviour (discovery metadata, PKCE, dynamic registration, unknown-client handling) Endpoint probe: node scripts/probe.ts on 2026-10-30 · Facebook's OIDC discovery only describes Limited Login (implicit id_token); no PKCE methods advertised, no dynamic registration. /v21.0/dialog/oauth with an unknown client_id returns HTTP 200 with an HTML error page. | confirmed |
| Microsoft (Graph: Outlook mail and calendar) | Client secrets max 24 months Fetched how-to-add-credentials · Microsoft also recommends under 12 months and says secrets should not be used in production. | confirmed |
| Microsoft (Graph: Outlook mail and calendar) | Partner Center verification takes days Fetched Partner Center verification process page · Three to five business days in most cases. | confirmed |
| Microsoft (Graph: Outlook mail and calendar) | Microsoft-managed default consent policy excludes Mail.Read, Mail.ReadWrite, Calendars.Read/ReadWrite, Contacts.ReadWrite, Files.Read.All...; Mail.Send is not excluded; default for new tenants Independent check: re-fetched learn.microsoft.com 'Manage app consent policies' (ms.date 2026-01-22, updated 2026-08-28) on 2026-10-30 · List also includes MailboxSettings.*, Tasks.*, People.Read, Chat.*, OnlineMeetings.* and EAS/EWS/IMAP/POP for Exchange. Mail.Send absent. | confirmed |
| Microsoft (Graph: Outlook mail and calendar) | Client secrets max 24 months; Microsoft recommends under 12 and says secrets should not be used in production Independent check: re-fetched learn.microsoft.com 'Add and manage app credentials' on 2026-10-30 | confirmed |
| Microsoft (Graph: Outlook mail and calendar) | Partner Center business verification typically 3-5 business days Independent check: not re-fetched; relies on s7 only | unverified |
| Microsoft (Graph: Outlook mail and calendar) | OAuth endpoint behaviour (discovery metadata, PKCE, dynamic registration, unknown-client handling) Endpoint probe: node scripts/probe.ts on 2026-10-30 · Entra's v2.0 discovery is found only under the tenant path, does not advertise PKCE methods (Entra supports S256 in practice, not shown here) and has no dynamic registration. Unknown client_id on /common/oauth2/v2.0/authorize returns HTTP 200 with an HTML error page. | confirmed |
| Slack (Slack app, OAuth v2) | Non-Marketplace apps get conversations.history/replies at 1 request/min and 15 objects from 29 May 2025 Fetched Slack's changelog entry and the 3 June 2025 clarification · Applies to commercially distributed (unlisted) apps: new apps and new installs. Internal customer-built apps keep 50+/min and 1,000 objects. | confirmed |
| Slack (Slack app, OAuth v2) | Existing installs of unlisted apps were throttled from 3 March 2026 Compared community posts (DEV, vendor docs) with Slack's own changelog page · Slack's changelog as fetched still says existing installations are not affected; the March 2026 date appears only in third-party sources. | unverified |
| Slack (Slack app, OAuth v2) | Marketplace review takes weeks Fetched the Marketplace review guide · Up to 10 business days preliminary, up to 10 weeks functional (6 for resubmissions); 10 active workspaces required first. | confirmed |
| Slack (Slack app, OAuth v2) | Non-Marketplace commercially distributed apps: conversations.history/replies at 1 req/min, limit 15, since 29 May 2025 for new apps and new installs; Marketplace and internal apps keep 50+/min, 1,000 objects Independent check: re-fetched the Slack changelog of 2025-05-29 on 2026-10-30; the method page still shows Tier 3 (50+/min) as the default · Existing installations of older non-Marketplace apps kept the old limits per the changelog. | confirmed |
| Slack (Slack app, OAuth v2) | Marketplace: 10+ active workspaces to submit; preliminary review up to 10 business days; functional review up to 10 weeks for new apps; *:history, files:read, search:read.* get enhanced review Independent check: fetched docs.slack.dev Marketplace review guide and app guidelines on 2026-10-30 · Active = used in the past 28 days; the 10-week clock starts when a reviewer is assigned. | confirmed |
| Slack (Slack app, OAuth v2) | OAuth endpoint behaviour (discovery metadata, PKCE, dynamic registration, unknown-client handling) Endpoint probe: node scripts/probe.ts on 2026-10-30 · Slack's discovery covers only Sign in with Slack (OIDC), not the v2 bot-scope flow; no PKCE methods advertised and no dynamic registration. /oauth/v2/authorize with an unknown client_id returns HTTP 200 with an HTML page. | confirmed |
The setup agent
Guides say what an agent can do; for GitHub the repo includes one that does it. scripts/setup-github.ts opens a real browser on GitHub's "Register a new GitHub App" page, fills every field from the developer profile, and stops at the two places a human must act: signing in (password, 2FA) and the final Create click. It then reads back the client id and tells you where to generate the secret. It never sees your password and stores nothing.