App registration guide

Source: en/guide/registering-apps.md · Live: https://docs.1pass.dev/en/guide/registering-apps LLM-sanitized: internal links absolutized, VitePress containers → admonitions, line numbers in the Jump-to Index reference this rendered file (1-indexed).

📍 Jump-to Index

• L45-L52: ## Prerequisite — email verification (from 2026-05-28)
• L53-L67: ## Automated risk assessment (creation_risk_flags)
• L68-L74: ## Rate limit
• L75-L78: ## Registering from CLI / MCP automation
• L79-L89: ## Registration form fields
• L90-L95: ## Issued values
• L96-L110: ## Client type
• L111-L120: ## Registration type classification (by Redirect URI host)
• L121-L126: ## Redirect URI rules
• L127-L148: ## Promotion to production
  • L131-L140: ### Application
  • L141-L148: ### Outcome
• L149-L158: ## Login method restriction
• L159-L164: ## Type transitions
• L165-L182: ## Edit / delete
  • L170-L182: ### Renaming the callback path (brand consolidation, route cleanup)
• L183-L190: ## FAQ
• L191-L194: ## Contact
• L195-L202: ## LLM-friendly version

---

App registration guide

• Sign up: https://start.1pass.dev/console/signup
• Register: https://start.1pass.dev/developer/applications/new

App and scope registration/management happen in the Developer Console (web) and the logi CLI. MCP currently supports app lookup plus redirect URI add/remove only. The native iOS/Android consumer apps are for end-user accounts and do not provide app/scope registration.

⚠️ Warning: OAuth host — standardize on api.1pass.devIssuer and discovery are fixed at https://api.1pass.dev: /.well-known/openid-configuration and /.well-known/jwks.json exist only on api.1pass.dev; start.1pass.dev returns 404 for discovery, and the iss in id_token is https://api.1pass.dev.

/oauth/authorize, /oauth/token, and /oauth/userinfo respond on both hosts, but RPs should standardize every endpoint on api.1pass.dev. This keeps issuer matching and discovery unambiguous. The console's "test with curl now" snippet may be generated against the console host (start.1pass.dev), so replace the host with api.1pass.dev. The authoritative value is always https://api.1pass.dev/.well-known/openid-configuration.

💡 Tip: One-pass CLI registration To complete developer registration → email verification → RP registration → secret capture from the CLI, see the step-by-step CLI RP registration guide (Korean), which includes a copyable prompt and verification checklist.

Prerequisite — email verification (from 2026-05-28)

To prevent a scenario where AI agents create large numbers of RPs automatically, logi allows RP registration only from email-verified accounts.

• A confirmation email is sent right after sign-up. RP registration is enabled once you click the verification link.
• Didn't receive the verification email? Resend it with the "✉️ Send verification email" button on the console /account or /console page.
• If you call while unverified: the web redirects to /developer/applications with an alert, and the API/CLI/MCP returns HTTP 403 {"error":"identity_verification_required","verify_url":"..."}.

Automated risk assessment (creation_risk_flags)

At registration, if the RP metadata matches any of the following signals, a risk flag is attached in the admin queue. You must pass the acknowledgement gate in the security guide before production approval:

Signal	Trigger
wildcard_redirect_uri	* in the redirect_uri
sensitive_scope	Requests a broad-permission scope like admin
unlisted_scope	A scope outside the standard set (openid/profile:basic/email/phone/offline_access)
high_volume_developer	The same developer registers 5+ apps within 7 days
new_developer_account	The developer account signed up within the last 7 days
suspicious_app_name	A placeholder name like test, sample, foo, untitled, or app123

Even with risk signals, registration itself goes through, but the app is unusable while status: pending. It is promoted only after an admin reviews it and explicitly approves it as "approved with full awareness of the risk."

Rate limit

• POST /developer/applications — 10/hour and 30/day per developer
• POST /api/v1/applications (CLI/MCP/PAK) — the same cap per PAK token

On exceeding the limit: HTTP 429 {"error":"rate_limited"} + a Retry-After header.

Registering from CLI / MCP automation

When using your own script, the logi CLI, or MCP, include the X-Logi-Client-Type: cli|mcp|api header. The audit log records the exact created_via channel → useful for detecting automated bulk registration.

Registration form fields

Field	Description	Example
App name	The display name on the consent screen	My App
Client type	Confidential / Public	Confidential
Redirect URIs	OAuth callback URLs (exact match, multiple allowed)	http://localhost:4000/auth/callback
Webhook URL (optional)	The user-event endpoint	https://app.example.com/webhooks/logi

Enable scopes under App detail → Manage Scopes, not in the registration form.

Issued values

• client_id — logi_... prefix, safe to expose
• client_secret — issued for Confidential only, shown only once right after saving. If lost, go to App detail → Re-issue secret (this invalidates the old one immediately)
• LOGI_RP_HEALTH_SECRET — logi_rphs_ prefix. It is shown once on the same page right after registration (the CLI also includes it in the logi apps create response). Store it only in the RP backend env; never in a client bundle or Git. It signs health-check HMACs; see RP Active Health Check. If lost, rotate it in the console or with logi apps rotate-secret <id>.

Client type

	Confidential (default)	Public (PKCE-only)
For	RPs with a backend	Mobile and SPA standalone
Secret	Issued	None
Authentication	HTTP Basic / form body	PKCE S256 enforced

iOS / Android / Web should each register a separate client_id per platform.

⚠️ Warning: If you split client_id, you must identify users by canonical_sub logi issues a different pairwise sub per client_id. So the same user receives a different sub for each platform (client_id). If the RP keys users by sub, the second platform login can fail with "already linked to another account" (AlreadyLinkedError).

Identify a person by canonical_sub (= the logi user.id, always emitted by userinfo, changes only on merge), which is identical across all clients. → Sub policy

Registration type classification (by Redirect URI host)

Type	Condition	Auto-approval	Token lifetime
Dev (local)	localhost, 127.0.0.1	✅ Immediate	Short
Dev (internet)	*.staging.*, *.test.*, *.localhost	✅ Immediate	Short
Production	A real service domain	⏳ Admin review	Normal

When registering multiple redirect_uris, the app is classified by the strictest type.

Redirect URI rules

• Exact match: byte-for-byte. Any difference in query/fragment/trailing slash is rejected
• No wildcards: *.vercel.app and the like are not allowed
• HTTPS enforced: only localhost / 127.0.0.1 may use http://

Promotion to production

Adding an external-domain redirect_uri sets status=pending. External-domain callbacks are rejected until the app is promoted.

Application

1. App detail → "Apply for production promotion"
2. The form:
   • Business registration certificate, PDF (required)
   • Service description (20+ characters)
   • Technical contact email
   • Agreement to the logi terms of service + DPA
3. Submit → a Telegram notification goes to the admin

Outcome

Outcome	Meaning
✅ Approved	tier=production, status=approved. External domains can be used
❌ Rejected	The reason is sent back by email and FAB
⏸ On hold	changes_requested. Reapply after addressing the feedback

Login method restriction

The login method restriction checkboxes in the app settings let you limit, per app, which methods appear on the login screen (Apple/Google/Kakao SSO · email/password · the logi app).

• Leave all checkboxes empty (the default) to show everything
• Only the checked methods are shown, and the hidden SSO/QR/push entry paths are also blocked on the server
• To narrow it per request only, use the provider parameter on the authorize URL

For the full behavior and priority rules, see the login method restriction page.

Type transitions

• Local → internet: adding a *.staging.* redirect_uri transitions automatically — no application needed
• Internet → production: adding an external domain sets pending. A promotion application is required
• After production promotion, changing the redirect_uri may trigger re-review

Edit / delete

• Edit: App detail → Edit. You can change the name, redirect_uri, webhook, and allowed_scopes. Adding an external domain triggers re-review
• Delete: Delete at the bottom of App detail. The client_id is rejected immediately, issued tokens are revoked, and this cannot be undone

Renaming the callback path (brand consolidation, route cleanup)

When the SP changes the callback path itself (e.g. /auth/1pass/callback → /auth/logi/callback), a zero-downtime cutover is essential. Deploying only one side triggers invalid_request: redirect_uri not registered immediately.

Recommended order:

1. IdP first: add the new path to redirect_uris (keep the old path too — put both in the array)
2. Deploy the SP: start using the new path in code — in-flight sessions keep calling back to the old path
3. Grace period: confirm via the IdP logs that traffic to the old path has dropped to zero (typically 7+ days)
4. Remove the old path: delete it from redirect_uris

For pre-deploy verification, see the curl preflight in oauth/troubleshooting.md regression prevention.

FAQ

Vercel preview URLs: wildcards are unsupported. We recommend splitting off a dedicated preview sandbox app.

Re-viewing the client_secret: not possible. Use Re-issue secret for a new value (the old one is invalidated).

No business registration certificate: a sole proprietor works. With neither, you get the sandbox tier only.

Contact

Developer console (start.1pass.dev), bottom-right 💬 FAB → the admin's Telegram.

LLM-friendly version

curl https://docs.1pass.dev/llms/guide/registering-apps.md

Full bundle: https://docs.1pass.dev/llms-full.txt