How customers authorize
Vault is an embeddable component that lets your customers connect their own accounts. They authenticate directly with QuickBooks, NetSuite or Xero; Apideck stores and refreshes the credentials. You pass a consumer id and never touch a token.
The auth you didn't build. And don't maintain.
OAuth 2.0 where the provider offers it, API keys and session-based auth where it doesn't. Vault presents whatever that connector needs.
Tokens are stored and refreshed by Apideck. Nothing sensitive lands on your servers, so nothing sensitive is yours to leak.
Embed it in your product or hand off to a hosted page. Either way the customer signs in on the provider's own screen.
Vault has its own APIs and webhooks — connection created, updated, deleted — so your app reacts without polling.
Two ways to ship it. Same session underneath.
Embedded keeps the customer in your app; hosted is a redirect and no frontend code. Pick the one that matches how much control you want over the moment they connect.
Drop the component into your app and open Vault as a modal. Your customer never leaves your product.
- Smoother UX — the flow happens in place
- You need callbacks for connection events
- You want control over when and where it opens
@apideck/vault-js — one dependency, one call.
- 1Create a sessionyour backend calls POST /vault/sessions
- 2Open the modalVault.open({ token }) with the session token
- 3Customer authorizeson the provider's own screen
- 4onConnectionChange firesyour app updates without a page load
Vault is an API too.
Everything the widget does, you can do programmatically: list a consumer's connections, update settings, revoke a connection. Webhooks tell you when a customer connects, disconnects or updates one.

vault.connection.createda customer authorized a new connectorvault.connection.updatedsettings or credentials changedvault.connection.deleteda customer revoked accessvault.connection.callablethe connection finished setup and is ready to callEvent names shown as an illustration of the shape — check the reference for the current list.
When a resource isn't consented. You get told, clearly.
A customer's authorization covers a specific set of scopes. Ask for something outside them and Apideck doesn't fail vaguely — the response says which resource wasn't consented, so your app can send the customer back through Vault to grant it.
The connector decides what a given authorization covers. A consumer can be happily connected and still not have granted the scope your call needs.

Their tool, their login screen.
Same Vault session, whichever they pick — and the same unified API afterwards.