A tenant-chosen numeric PIN (at least four digits) that gates the Integrations tab. The PIN is stored only as a hash — never stored raw, never logged, never returned. Failed attempts are throttled with a lockout, and a reset link goes to the requesting admin's own mailbox. The control that turns the PIN on, changes it or turns it off lives behind the gate itself.
Also called: password protect integrations · second password · lock the api keys · PIN
- 1A status call reports whether the lock is enabled and whether this session is unlocked.
- 2Verify checks the PIN server-side; failures return how many tries are left before a lockout window.
- 3Request reset mails a single-use token, hashed at rest, to the admin's own address, valid for 30 minutes.
- 4The gate is a front door, not the lock: the server refuses the credential route outright with a 423 without a valid unlock.
- 5Platform staff who pass the gate see a banner saying so and that the access is logged.
Bug, from a named customer. The migration quotes Brad Garber (Graber): 'Could we protect this with a password or pin?' and states the reasoning: the tab is already admin-only and server-enforced, 'but role is a property of the account, not of the moment: an admin who leaves a laptop open, or whose session is borrowed, hands over every connected service.' Storing the raw reset token is rejected in the same comment because it 'would make the table itself a bypass of the thing it protects'. Optional by design — 'a tenant who doesn't want it never sees it'.
- Admin role granted permanent access to decrypted third-party credentials from any open session.
- There was no second factor at the point of access.
- A forgotten PIN would have locked the owner out of their own integrations.
See it on your own jobs
Twenty minutes, your numbers, no slide deck. We’ll build one of your real buildings in front of you and send you the estimate link at the end — yours to keep either way.
or keep browsing features →