Skip to main content
Every API request is authenticated with a Bearer token in the Authorization header:
There are two kinds of tokens:
  • Personal access tokens: for your own scripts and server-to-server calls against your own Synci account. No OAuth flow needed.
  • OAuth access tokens: for apps that other Synci users authorize. Obtained through the OAuth 2.0 authorization code flow with PKCE. See Building OAuth apps.
Both token types are sent the same way and are subject to the same scope checks.

​
Personal access tokens

Create a token in the Synci dashboard under Developers → Tokens:
1

Create the token

Click New token and give it a descriptive name (for example, “Reporting script”).
2

Restrict it, optionally

Restrict the token to specific scopes (see the table below) and specific bank accounts. A token with no scope restriction has full access to your account.
3

Copy it immediately

For security the token is displayed only once. If you lose it, delete the token and create a new one.
Personal access tokens are valid for 1 year. You can revoke a token at any time from the same page.
Migrating a legacy token? Tokens issued in the older {id}|{secret} format keep working for a limited deprecation window but are being retired. Regenerate the token in Developers → Tokens and update your integration.

​
OAuth access tokens

If you are building something other Synci users will connect to, register an OAuth app under Developers → Apps. Users approve your app on a consent screen, choose which accounts to share, and your app receives:
  • An access token, valid for 1 hour.
  • A refresh token, valid for 30 days, which rotates on every use.
The full flow, including PKCE, token exchange, and refresh, is covered in Building OAuth apps. If your users will never hold a Synci account, a Managed app mints tokens for them server-to-server instead, with no consent screen. See Managed apps.

​
Scopes

Scopes control what a token may do. Personal access tokens can optionally be restricted to a set of scopes; OAuth apps must request them and the user must approve them.
Request the least you need. Users are more likely to approve an app that asks only for what it needs, and app reviews go faster.

​
Sensitive identifiers are redacted by default

For third-party apps, sensitive identifiers (IBAN, BBAN, account and card numbers, account holder names) are always redacted unless the user granted sensitive:read. This is enforced server-side and cannot be switched off by the caller. sensitive:read on its own grants nothing; it un-redacts fields on data you can already see through accounts:read or transactions:read.

​
Account selection

Some scopes are account-scoped. When a user authorizes an OAuth app with account-scoped permissions, they pick exactly which accounts the app may access. Personal access tokens can be restricted to specific accounts the same way when you create them.

​
How authorization failures look