Connect a lock in 60 seconds
Connecting hardware is one call and one redirect. You never see the user's lock credentials, and you never write brand-specific login code.
Build it with your AI agent
Install the Seam plugin and your coding agent picks up three integration skills: Reservation Automations, Access Grants and Access Codes. It then writes the calls the way we would. Paste the prompt below and let it build.
1. Install the plugin
The Claude Code install also adds our documentation MCP server, so the agent can look up endpoints and device capabilities while it works. Cursor, Codex and other agents get the skills through npx skills add and can add the MCP server there separately.
2. Paste this prompt
What you can build
Onboarding that survives brand variety
Property managers show up with August in one building and Schlage in the next. One webview handles every brand's login, multifactor prompts and error states, so onboarding is the same flow no matter what is on the door.
A device list that stays current
Once an account is connected, locks added to it later flow into Seam without another login. Your sync job lists devices and picks up the new hardware.
Capability-aware UI
Every device carries capability flags, so your app can show a PIN pad only for locks that take codes and a remote unlock button only where it will work. No brand matrix to maintain by hand.
How it works
Install the SDK and export your API key
Create a workspace in Seam Console, generate an API key under Developer > API Keys, and export it as SEAM_API_KEY. Start in a sandbox workspace: it comes with virtual locks, so you can run this whole flow before touching real hardware.
Create a Connect Webview
One call from your backend. accepted_providers narrows the brand list to what your product supports; leaving it off shows every stable brand. The response carries a url for your user and a connect_webview_id you keep, because the id is how you find out what happened after they finish.
Open the url and let your user log in
Open the url in an iframe or a new window. Your user picks their brand and signs in with their own account. Seam runs the credential validation and any multifactor step, and sends them to your custom_redirect_url when the connection is made. Their password never passes through your servers, which keeps that login out of your security scope.
Verify the connection and list the devices
Fetch the webview by id. status authorized with login_successful true means the account is connected, and connected_account_id scopes a device list to exactly what this user linked. Read the capability flags off each device before you offer actions in your UI: a lock that cannot take codes should never show a PIN screen.
React to new hardware over time
Accounts change after onboarding: locks get added, batteries die, someone renames the front door. Re-list devices on a schedule or subscribe to device lifecycle events with a webhook, and treat the device list as state you sync instead of a one-time import.
Frequently asked questions
Do my users need a Seam account?
No. They log in with their existing lock account, the one from the lock's own app. Seam sits between your app and the brand's cloud; your users never see Seam.
Which smart lock brands can my users connect?
Dozens, including August, Yale, Schlage, Kwikset, TTLock, Nuki, Tedee and igloohome, plus access control systems like Salto and Brivo. The supported devices page lists every model, and accepted_providers controls which ones your webview offers.
Should I open the webview in an iframe or a new window?
Both work across modern browsers. An iframe keeps the user in your flow and suits onboarding wizards; a new window is simpler when your app is mobile web. Either way, the custom_redirect_url brings the user back when they finish.
What happens when my user adds a lock to their account later?
New devices on a connected account flow into Seam without another webview. List devices again, or subscribe to device events, and the new lock is there with its capability flags set.
How do I test this without buying a lock?
Sandbox workspaces come with virtual devices for every major brand. The webview flow, the device list and the capability flags all behave like production, so you can build the whole feature before hardware arrives.
What do I store on my side?
The connect_webview_id while the flow is in progress, then the connected_account_id and the device_ids you care about. Keep the API key server-side; the webview url is the only thing the browser needs.
Related
- Smart lock API overviewEvaluate supported brands, connection requirements, and the workflows your app can build.
- Connect Webviews documentationThe full flow, customization options, and every field on the connect_webview object.
- How to generate temporary access codes programmaticallyThe next step once locks are connected: issue time-bound PIN codes from your app.
- Smart locks that support remote unlockEvery model you can unlock over the internet once its account is connected.
- Every device and system Seam supportsSearch the whole device database by brand, device type and capability.