Skip to main content
These are the most common questions from partners building integrations. If yours isn’t here, ask your 1Password contact in your shared Slack channel.

​
Getting started

A service account gives a program standing access to whole vaults, and the person has to set it up and hand you its token. With Agentic Autofill:
  • The person connects with a standard web OAuth flow at 1password.com. There’s no token for them to create or paste.
  • The person approves specific logins, for a stated goal, in their 1Password app. Your integration can use only those.
  • With extension fill, your platform and the model never handle the values. The extension fills the page.
  • The person’s items stay end-to-end encrypted, and your integration never holds their vault keys.
No. There’s no 1Password app to install on your side. You load the 1Password browser extension into the Chromium browser your agent drives and call it over CDP. Any VM or sandbox in your setup is your own. The integration works on any operating system with a Chromium build that supports extensions.The person does need a 1Password app on their own device, signed in to the account they connected, to approve requests.
Test on 1password.com. Register your OAuth client in your company’s 1Password Business account, and use a separate Individual or Family account in the US as your test user. An existing personal account works, or sign up for a new one. Don’t use your Business account as the test user: Business accounts don’t get the consent screen. The development environment, b5dev.eu, can’t show approval prompts with current 1Password app builds. See the Quickstart.
Only Business accounts can register OAuth clients. Register your client in your own company’s Business account on 1password.com, and choose Business, not Teams. Keep the account active: the approval prompt looks up your client there. Your end users connect with their Individual or Family accounts.
No. The 1Password app reads your integration’s name and icon from your OAuth client registration. See Go to production.
1Password for Mac, Windows, or Linux on the Nightly release channel: Settings > Advanced > Release channel > Nightly. Sign it in to your test account on 1password.com, and open approval links on that computer. Mobile approval isn’t available to test yet.
Use the development build of the 1Password extension that 1Password sends you, loaded unpacked or with the extension installation mechanism your browser stack uses. 1Password will announce in your partner channel when Agentic Autofill is in the Nightly, Beta, or Stable channel on the Chrome Web Store, and when to switch. See Load the extension.
Start with the browser extension. If your product needs the SDK, for example to ask for access before a browser exists, contact 1Password for guidance before you build with it, so we can review our shared security model with you. See Use the SDK.

​
Connecting users

You don’t need it. Everyone authorizes at https://my.1password.com. Don’t ask the person for their account address. See Base URLs and endpoints.
There are two common causes. The authorize path must be /oauth/authorize, with no /v1. At launch, the consent screen appears only for Individual and Family accounts. In development, it’s also available for Business accounts.
1Password returns an integration key only when it creates a new one: on a person’s first consent, or their first consent after you revoked the connection. If the person connects again while their key is still active, the callback has no key. That’s normal. Keep the key you stored. See When you receive a key.
Revoke the connection from your backend with self:revoke, then connect again. The new consent returns a new key. A person can’t revoke from inside 1Password, so there’s no screen for it in the account. See Disconnect a user.
Key your storage on the connection path inside the integration key: it names one OAuth client, account, and user. The token response can include user_id. Compare it with the user in the stored key’s path. If they don’t match, the person connected a different account and you don’t have a key for it: revoke and have them connect again. Treat token strings as opaque rather than parsing IDs out of them.
Send them a connect link. In the browser, it starts a 1Password account sign-up with their name and email address filled in, and the verification email names your product. Sign-up doesn’t connect the account to your product, so connect the person with the authorization URL after they finish. Connect links are in development: check availability with your 1Password contact.
It’s in development. A connect link will open the consent screen inside 1Password for iOS, already signed in, and then return the person to your app. Until that ships, people connect in the browser.
No. Redirect URIs must use https. Use a universal link or app link, or a web page that hands the result back to your app. Your callback also has to read the URL fragment in a browser, because the integration key arrives there.
Most often because you sent client_id in the form body as well as the HTTP Basic header. Authenticate with HTTP Basic only. See Token exchange and refresh.
Register and own your own OAuth client, and pass the token, integration key, and reference to whichever service fills. The connection then belongs to you, so you can use more than one browser provider, or switch providers, without asking people to connect again.
In your backend, in a per-user secret store, protected at least as well as a refresh token. Give a browser session only a current access token and the integration key, in memory, for the length of a task. See Store keys and tokens.

​
Requests and approval

The extension packages everything a browser agent needs: create, wait, and fill, with no other component. There’s no separate HTTP endpoint for access requests. If your product needs to create requests outside the browser, contact 1Password for guidance and a review of our shared security model.
No. 1Password keeps the request. You can check its status later from a new browser session, with the same person’s token and integration key. The status call returns right away, so you poll it. If you poll from the browser, keep one CDP session attached while you do.
No. Approving a login is cryptographic work that needs the person’s vault key, and only their 1Password app holds it. That’s what stops a compromise of your platform from creating grants. Connecting over OAuth lets you ask for logins; it doesn’t grant any.Ways to approve from inside your own iOS or Android app, still with 1Password doing the approval, are in development. Ask your contact if you’re building a mobile app.
The person approves once per login, not once per fill. After approval, your agent can fill that login as often as tasks need, for the life of the grant. To keep prompts down, batch every login a task needs into one request, and reuse references you already hold.Shared vaults aren’t supported at launch, and wouldn’t remove the approval step: approval is where the person’s app gives your integration the keys for a specific item, wherever it lives.
At launch, a grant stays valid for 30 days, and configurable lifetimes are planned. A grant isn’t tied to a chat session. If your product promises approval per session, create a new request each session and don’t reuse old references. See How long a grant lasts.
Yes, within a grant’s lifetime. Fills don’t involve the person or their 1Password app, so an agent can fill an approved login while the person is away. When a grant ends, the person has to approve again. Longer-lived access for scheduled jobs is planned.
Not yet. Approval works today in 1Password for Mac, Windows, and Linux on the Nightly release channel. Approval in the 1Password mobile apps, and from inside your own mobile app, are in development. The person’s 1Password app must be signed in to the account they connected.
From your OAuth client registration. The consent screen and the approval prompt both show the name and icon you entered when you created the client. You can’t add an icon after a client is created, so if you registered one without an icon, register a new client.
The result may not match your entries one to one. A requested entry may have no corresponding grant because the person granted nothing for it, and a granted login can have no entryId because the person added one you didn’t ask for. Match on entryId, never on position. See Read what the person granted.
Not at launch. The goal, reasons, keywords, and websites travel to the person’s 1Password app inside the approval link, as readable base64url JSON. Treat the link as sensitive, and keep personal data out of request text. Encrypting these fields is planned.

​
Filling

You get a reference for each granted login, a string such as //api.1password.com/credential-broker/accounts/<account>/capability/login/configurations/<id>. It’s a pointer, not a credential and not an encrypted payload, and you don’t transport any secret material. When you call fillCredential with the reference, the extension fetches the login from 1Password’s credential broker over an attested, encrypted session, fills the form, and submits it. See Security model.
Every extension call takes a current access token and the integration key. There’s no narrower session key yet. Pass both from your backend when a task starts, keep them in memory, and drop them when it ends. The access token expires after 15 minutes. The refresh token and client secret never go to the browser.
Yes. It works with any Chromium browser, remote or local, that can load an unpacked extension and give you a CDP connection. Load the extension when you create the browser, and run one person per browser. If your provider drives the browser through its own automation API, you still need a CDP connection for the extension calls.
Yes. Agentic Mode stops normal 1Password browser behavior, such as inline suggestions and save prompts, from exposing the person’s state in pages your agent controls. Turn it on with api.agenticMode.v1.enable every time your agent starts working in the browser, for one tab or the whole browser. A fill in a tab it doesn’t cover fails with agenticModeNotEnabled. See Turn on Agentic Mode.
You have to make sure the model and agent can’t read the page until fillCredential returns, because the values are in the page between fill and submit. How you do it is up to you. If the browser runs on a different machine from the model, holding agent actions until the call returns is enough. A lock in your orchestrator that blocks DOM reads, screenshots, and other CDP commands to the tab also works.
No. When fillCredential returns fill_submitted, the form was submitted and the filled values are no longer present on the page. When it returns fillFailed or autosubmitFailed, 1Password clears what it filled before it returns.
No. It means 1Password filled and submitted the form. The website may still reject the login or ask for another step. Check the page after the call returns.
Yes, but 1Password doesn’t distinguish between them: they share one token and one integration key. If agent A mustn’t use logins granted for agent B’s task, enforce that in your system, for example by storing references per task and letting each agent use only its own.
Not at launch. Every extension call takes both. Keep them in memory for the length of a task, and keep the model off the page during fills. 1Password is looking at ways to keep them out of the agent’s browser.

​
Scope and roadmap

Individual and Family accounts on 1password.com in the US, the person’s own vault, and logins with a username, password, and one-time password, filled into Chromium browsers. See What’s supported.
Not at launch. Both are planned.
Not at launch. Business accounts, shared vaults, and admin controls over agent access are planned. Tell your contact which of these your product needs and why.
Not at launch. Revocation ends the person’s entire connection. To stop using one login, stop filling it and drop its reference. See Disconnect a user.
Not at launch. The person disconnects from your product, so make Disconnect 1Password easy to find.
Your agent uses 1Password through the browser extension. If your product needs credentials outside a browser, contact 1Password for guidance and a review of our shared security model before you build with the SDK.

​
Going to production

Now. Production is live: OAuth connect, token exchange, refresh, and revoke work on 1password.com, and approval works in the 1Password desktop app on the Nightly release channel. Tokens and integration keys from the development environment don’t work on production, so connect your test user again and store the new key.
The person creating the client must be an owner, an administrator, or in the Security group, and 1Password has to turn the feature on for your account. Send your contact an admin’s email address. After it’s on, sign out and back in. See Accounts and setup.
You enter the redirect URL yourself when you create the OAuth client. Register a separate client for each of your own environments, each with its own redirect URL.
Register a new client with an icon: PNG, JPEG, or GIF, up to 1 MB. You can’t add an icon after a client is created.