App registration guide

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

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/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)

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.

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