AlkiraiLink API

Bank data for the Caribbean, through one API

A person connects their accounts at an institution through AlkiraiLink Connect. Your server then reads their accounts, balances and transactions with one API, whatever the institution runs underneath.

How it fits together

1. Your server starts a Connect session with POST /v1/connect/sessions and gets a link_url.
2. The person signs in through Connect, in their browser or in your app's web view. They type their details into Connect, never into your app.
3. Connect sends them back to you with a public_token, and your server exchanges it for a connection_id with POST /v1/connect/exchange.
4. Your server reads the connection whenever your app refreshes: POST /v1/connections/{connection_id}/refresh returns accounts and new transactions together.

Client ID and secrets

Your app has one client ID and a secret for each environment. Every request goes to https://api.alkirai.com with the client ID in the X-Client-Id header and a secret in the X-API-Key header. Send them from your server only: a secret in an app can be read out of it.

• The client ID names your app. It is the same in the sandbox and live, it never changes, and it is not a secret: quote it to us when you write in.
• The sandbox secret starts alk_sandbox_. It sees the sandbox institutions and nothing else. They take fixed test details, and nothing you do with them reaches a real institution. See Sandbox.
• The live secret starts alk_live_. It sees real institutions, and never the sandbox ones.

Which environment a request reaches is decided by the secret alone, so moving from the sandbox to live is a change of one value. A secret is shown once, when it is made; rotate it to replace it, and the old one keeps working for the grace period you choose.

AlkiraiLink is in early access, and client IDs and secrets come from our team. Write to hello@alkirai.com with what you're building.

What works differently here

AlkiraiLink reads each institution through its online banking, signed in as the person. Four things follow, and each has a guide.

• Reading accounts or transactions signs in. Institutions watch how often an account signs in, so each connection has a sign-in budget. Read it without spending it, and prefer one refresh to separate reads. See Syncing and budgets.
• Your app decides when to refresh. AlkiraiLink sends no webhooks: nothing changes until your server asks.
• Not every institution can refresh on its own. sync_mode says whether a refresh needs the person, and runs_on says whether the sign-in happens on their own device. GET /v1/institutions reports both before anybody connects. See Connecting and Sign-in sync.
• A stopped connection says why. When an institution refuses a sign-in, the connection stops rather than trying again into a locked account, and its error says who has to act. See Errors.

Money

An amount is positive for money leaving the account and negative for money arriving. Every account and every transaction carries its own ISO 4217 currency, and one connection often holds accounts in more than one, so convert before you add balances together.

Every endpoint