Live on the Plaid network
Data access API
Consent-based access to looch accounts for authorized aggregators. One FDX-aligned REST API, OAuth 2.0 with PKCE, and approval that happens in the looch app. No screen scraping. No shared credentials.
Overview
looch is the financial OS for the modern business: Business accounts, payments, Smartcards, and accounting in one app. The data access API lets a looch business connect its accounts to the outside tools it relies on, from payment apps to lenders, through the aggregator networks those tools already use.
The API is aligned with the
Financial Data Exchange (FDX) standard and supports API versions 6.1 through 6.3. It serves the Plaid network in production today, and this page is the reference for any aggregator integrating against it. Every connection starts with the looch business’s explicit approval, access is read-only, and data flows over authorized, tokenized API calls.
Environments
Production and development are separate stacks with separate credentials. Each publishes an OpenID Connect discovery document that is the source of truth for its endpoints.
The authorization page is public. The token endpoint and every resource endpoint accept requests only from the IP ranges each partner registers with us, in both environments.
Authentication
Authorization uses the OAuth 2.0 authorization code flow with PKCE (S256), which is required. The discovery document resolves to these values in production:
{
"authorization_endpoint": "https://auth.looch.money/oauth2/v1/authorize",
"response_types_supported": ["code"],
"scopes_supported": ["openid", "offline_access"],
"token_endpoint": "https://auth.looch.money/oauth2/v1/token",
"token_endpoint_auth_methods_supported": ["client_secret_basic"],
"jwks_uri": "https://auth.looch.money/oauth2/v1/jwks"
}
1. Redirect the looch business to the authorization endpoint. Include your registered client_id and redirect_uri, along with state and the PKCE challenge:
GET https://auth.looch.money/oauth2/v1/authorize
?client_id=YOUR_CLIENT_ID
&redirect_uri=https://your-service.example/oauth/return
&response_type=code
&scope=openid offline_access
&state=OPAQUE_STATE_VALUE
&code_challenge=BASE64URL_S256_CHALLENGE
&code_challenge_method=S256
&prompt=login
2. The looch business approves in the looch app. looch is passwordless, so there are no banking credentials to type, store, or leak. The authorization page presents a QR code: The looch business signs into the looch app with their passkey and scans the code with the app’s built-in scanner to approve the connection. App-to-app authentication, where approval hands off directly into the looch app on the same device, is in development.
3. Exchange the code for tokens. We redirect back to your redirect_uri with an authorization code. Exchange it at the token endpoint using HTTP Basic client authentication and your PKCE verifier:
POST https://auth.looch.money/oauth2/v1/token
Authorization: Basic BASE64(client_id:client_secret)
Content-Type: application/x-www-form-urlencoded
grant_type=authorization_code
&code=AUTHORIZATION_CODE
&redirect_uri=https://your-service.example/oauth/return
&code_verifier=ORIGINAL_CODE_VERIFIER
The response carries the access token for resource calls, a refresh token (via offline_access) for long-lived connections, and an OpenID Connect ID token identifying the looch business. Verify token signatures against the published jwks_uri.
What a looch business can share
A looch business can share its deposit accounts: Primary Business, the operating account, and Tax Stash, the tax savings account. Accounts that hold funds earmarked for payouts (payments processing, payroll, and Smartcard settlement) are excluded by design and are never discoverable through the API.
Consent is explicit and per-connection. The looch business sees what they are sharing before they approve, and access lasts only as long as the connection does.
API reference
Resource endpoints live under the environment base URL and require the looch business’s access token as a bearer credential. The API implements the FDX account and transaction resources:
GET/accountsEvery account the looch business consented to share
GET/accounts/{accountId}Detail for a single account
GET/accounts/{accountId}/contactAccount holder name and contact details
GET/accounts/{accountId}/transactionsTransaction history for the account
GET/accounts/{accountId}/payment-networksRouting and account numbers for payment initiation
A shared account renders as an FDX deposit account:
{
"accountCategory": "DEPOSIT_ACCOUNT",
"accountId": "1024623.101",
"accountType": "CHECKING",
"accountNumberDisplay": "4021",
"productName": "Primary Business",
"nickname": "Primary Business",
"status": "OPEN",
"currency": { "currencyCode": "USD" },
"currentBalance": 18240.25,
"availableBalance": 18240.25
}
Transaction history excludes failed and blocked items, so activity reconciles cleanly against balances. The statements and asset transfer resources of the broader FDX specification are not offered: looch accounts are business deposit accounts, and those resources do not apply.
Getting connected
Aggregators and data recipients integrate under a data access agreement. Here’s the path from first contact to production:
Agreements
We put a mutual NDA and a data access agreement in place.
Registration
We exchange client credentials for both environments, delivered encrypted with the passphrase shared through a separate channel, and register your redirect URIs and source IP ranges.
Testing
We provision test profiles in the development environment and work alongside your engineers through validation.
Production
Production access is enabled and looch becomes discoverable to your users.
Start the conversation
Live uptime for every looch service is published on the status page.
Questions about an existing integration? Reach us through your partnership channel or at help@looch.money