DEV Community: Kate Apideck

How to Get Your Plaid API Key

Kate Apideck — Thu, 13 Aug 2026 07:54:01 +0000

Plaid is the financial data infrastructure company that connects applications to bank accounts. If your product needs to pull transaction data or verify bank account ownership, Plaid is probably on your shortlist. Most fintech apps in the US and Canada rely on Plaid to handle the messy reality of connecting to 9,600+ financial institutions through a single API.

You're here because you need a Plaid API key to connect your app. Here's how to get your credentials and make your first request without reading their entire documentation.

Prerequisites

Before you start, make sure you have:

An email address for your Plaid account (business email preferred for production approval)
A clear idea of which Plaid products you need (Transactions, Auth, Identity, Balance, etc.)
Node.js, Python, Ruby, Go, or Java installed if you want to use one of Plaid's official client libraries

Step 1: Create a Plaid account

Go to https://dashboard.plaid.com/signup and create an account. Plaid will ask for basic information about you and your company. Complete the signup process and acknowledge their terms of service. Plaid's own quickstart guide walks through the full flow if you want the longer version.

Once you're in, you'll land on the Plaid Dashboard. This is where you manage API keys and production access.

Step 2: Find your Plaid API keys

From the Dashboard, navigate to Developers > Keys (or go directly to https://dashboard.plaid.com/developers/keys). This is where Plaid stores your API keys.

You'll see two credentials:

client_id: A unique identifier for your application. This stays the same across all environments.
secret: An environment-specific key. You'll get a separate secret for each Plaid environment.

Plaid uses two environments:

Sandbox (sandbox.plaid.com): Free test environment with simulated bank data. No real financial institutions, no billing. This is where you build and test.
Production (production.plaid.com): Real bank connections, real data, real billing. Requires approval from Plaid before you can access it.

Your Sandbox secret is available immediately after signup. Copy it now.

Step 3: Understand how Plaid authentication works

Plaid's server-to-server authentication is straightforward. Every API request requires your client_id and secret, passed either as headers (PLAID-CLIENT-ID and PLAID-SECRET) or in the JSON request body. The full details are in Plaid's API overview.

There's no OAuth token exchange for server-side API calls. You send your credentials with each request. The OAuth-style flow in Plaid (called Plaid Link) is the client-side component your end users interact with when connecting their bank accounts. That's a separate concern from getting your API keys.

Step 4: Store your credentials securely

Add your client_id and secret to environment variables. Never hardcode them in your application code.

export PLAID_CLIENT_ID='your_client_id_here'
export PLAID_SECRET='your_sandbox_secret_here'
export PLAID_ENV='sandbox'

If you're using a .env file for local development, add it to your .gitignore immediately. Plaid secrets pushed to a public repository are a real risk, especially once you have production credentials.

Step 5: Set up billing (when you're ready for production)

Sandbox usage is always free. When you're ready to go live, you'll need to request Production access through the Dashboard by selecting Migrate to Production and filling out the application.

Plaid offers three pricing tiers:

Pay as you go: No minimum spend, standard per-use rates. Good for early-stage projects.
Growth: Annual commitment with lower per-use costs. Includes a personal account manager.
Custom: For high-volume usage above $2,000/month. Contact Plaid's sales team.

Your first 200 production API calls are free under Plaid's Limited Production access, so you can test with real bank connections before committing to a plan.

Test your Plaid API key

Create a test Item in the Sandbox using Plaid's sandbox-only endpoint. This bypasses the Link UI flow and lets you verify your credentials directly:

curl -X POST https://sandbox.plaid.com/sandbox/public_token/create \
  -H "Content-Type: application/json" \
  -d '{"client_id": "YOUR_CLIENT_ID", "secret": "YOUR_SANDBOX_SECRET", "institution_id": "ins_109508", "initial_products": ["transactions"]}'

A successful response returns a public_token. You can then exchange it for an access_token:

curl -X POST https://sandbox.plaid.com/item/public_token/exchange \
  -H "Content-Type: application/json" \
  -d '{"client_id": "YOUR_CLIENT_ID", "secret": "YOUR_SANDBOX_SECRET", "public_token": "PUBLIC_TOKEN_FROM_PREVIOUS_STEP"}'

If you get back an access_token and item_id, your credentials are working correctly.

Security best practices

Store your client_id and secret in environment variables or a dedicated secrets manager (AWS Secrets Manager or similar).
Use separate secrets for Sandbox and Production. Plaid generates different secrets per environment by default, so don't mix them up.
Add .env to your .gitignore before your first commit. Not after.
Never expose your secret in client-side code. All Plaid API calls (except Link initialization) should happen server-side.
Monitor your Plaid Dashboard for unexpected activity, especially after granting team members access.

Common gotchas

Mixing up environment URLs and secrets. Your Sandbox Plaid API key only works against sandbox.plaid.com. Your Production secret only works against production.plaid.com. If you're getting INVALID_API_KEYS errors, check that your environment URL and secret match.

Confusing Plaid Link with API authentication. Plaid Link is the client-side UI widget your end users interact with to connect their bank accounts. It produces a public_token that you exchange server-side for a permanent access_token. The client_id and secret are your server-to-server credentials, not something you pass to Link directly.

Forgetting to request Production access. Sandbox works immediately, but Production requires a separate application through the Dashboard. The approval process includes reviewing your use case, compliance requirements, and may take a few days. Plan for this lead time before your launch date.

Not handling the access_token lifecycle. Once you exchange a public_token for an access_token, that access token remains valid until you explicitly revoke it via /item/remove. There's no expiration, but you still need to handle error states (like when a user changes their bank password) through Plaid's webhook system.

Assuming all institutions support all products. Not every bank supports every Plaid product. If you request Auth for an institution that only supports Transactions, Link will fail. Check institution coverage before building your product selection logic.

Building financial integrations beyond banking data

If you're building a fintech application that needs both bank account data and accounting platform connectivity, the two sides of the integration stack are different. Plaid handles the banking layer: account verification and transaction feeds. (For more on how banks and apps connect, see our bank API integration guide.) The accounting layer, connecting to platforms like QuickBooks and Xero for invoices and financial reporting, requires a separate integration approach.

Check out our other API key guides for platforms in the accounting and finance space, including QuickBooks and Xero.

NetSuite OneWorld vs Standard: What Changes When You Hit the API

Kate Apideck — Tue, 11 Aug 2026 12:49:51 +0000

Every NetSuite instance is different. That is the first thing any integration team learns, usually the hard way. But the single biggest source of variation across NetSuite accounts has nothing to do with custom fields or SuiteScript extensions. It comes down to one question: is the account running OneWorld or not?

The answer changes the database schema your integration queries and the currency logic it has to handle. If you build a NetSuite connector that only works against Standard accounts, it will break the moment a OneWorld customer connects. If you only test against OneWorld, you will throw fatal errors on Standard instances that lack subsidiary tables entirely.

This post covers what actually differs between the two editions, where the API diverges, and what it means if you are building or buying a NetSuite integration.

How OneWorld and Standard editions differ at the schema level

NetSuite Standard runs a single legal entity. One set of books, one base currency. The subsidiary record does not exist. There is no subsidiary table to query, no subsidiary field on transactions, and no intercompany elimination logic.

NetSuite OneWorld adds multi-subsidiary support. Each subsidiary is a separate legal entity with its own base currency and tax schedules. The chart of accounts can be shared with the parent or customized per subsidiary. Subsidiaries are arranged in a parent-child hierarchy, and financial data rolls up through that hierarchy into consolidated reports.

Oracle prices OneWorld as a licensing upgrade on top of Standard, typically adding $10,000 to $30,000 per year depending on subsidiary count. Once enabled, the upgrade is permanent and cannot be reversed. Every edition of NetSuite (Light, Mid-Market, Enterprise) can be upgraded to OneWorld.

The practical difference for integration teams: OneWorld accounts have tables and fields that Standard accounts do not. And querying those missing tables on a Standard account does not return empty results. It throws a fatal error.

How the NetSuite OneWorld subsidiary field affects API queries

On a OneWorld account, nearly every transactional and master data record gains a subsidiary field. Invoices, bills, journal entries, customers, vendors, items, and GL accounts all carry subsidiary references. Some records, like customerSubsidiaryRelationship and vendorSubsidiaryRelationship, only exist on OneWorld accounts. Oracle's own REST API documentation states: "You must either use NetSuite OneWorld or have the Subsidiaries hidden feature enabled before you can use this record through REST web services."

On a Standard account, none of these fields or records exist. A SuiteQL query that JOINs the subsidiary table will fail with a "Record not found" error. A REST API call to the subsidiary endpoint returns nothing useful.

This creates a branching problem. For every resource you want to read from NetSuite (accounts, contacts, transactions, invoices, journal entries), you need at least two query variants: one that includes subsidiary JOINs and filters, and one that does not. Add multi-currency into the mix (which is a separate feature that may or may not be enabled, even on OneWorld accounts), and you need to JOIN the currency table conditionally too. For an accounting integration covering 15 or more resources, the Truto engineering team calculated this produces 60+ query variants that need to be managed at runtime.

Runtime feature detection for NetSuite OneWorld vs Standard

You cannot ask a NetSuite customer "are you on OneWorld?" and hard-code the answer. Accounts get upgraded. Modules get enabled. The only reliable approach is to probe the account programmatically at connection time.

The detection pattern is straightforward in concept: attempt to query the subsidiary table, and if the query fails, the account is not running OneWorld. Then cache that result and use it to select the right query templates for every subsequent API call.

In practice this means your integration layer needs a query routing engine. Every SuiteQL query template exists in at least two forms (with and without subsidiary JOINs), and the correct form gets selected based on the feature flags detected during the initial connection probe. This is architectural work that has to happen before you write a single line of business logic. For a deeper look at the full scope of NetSuite integration complexity, including governance limits and concurrency constraints, see our separate guide.

The same pattern applies to multi-currency. If the account uses multiple currencies, the currency table is available and transactions carry currency fields with exchange rate data. If not, querying that table fails. You need to detect and branch for this independently of the OneWorld check, because Standard accounts can enable multi-currency without upgrading to OneWorld.

Multi-currency handling across NetSuite editions

Standard NetSuite with multi-currency enabled supports transactions in foreign currencies against a single base currency. The system converts and posts to the GL in the base currency using the exchange rate at the transaction date.

OneWorld takes this further. Each subsidiary has its own base currency. A US subsidiary posts in USD, a UK subsidiary in GBP, a Japanese subsidiary in JPY. Transactions record in their original currency and convert to the subsidiary's base currency for GL posting. Consolidated reporting then translates subsidiary financials into the parent's reporting currency using separate consolidated exchange rate tables.

For API consumers, this means the same invoice can have three currency amounts that matter: the transaction currency (what the customer was billed in), the subsidiary base currency (what hits the local GL), and the consolidated currency (what appears on the parent's P&L). Your integration needs to know which one it is reading and which one it needs. The transactionLine records in SuiteQL carry fields like fxamount (foreign currency amount) and amount (base currency amount), and which "base" that refers to depends on the subsidiary context of the transaction.

If you are pulling a trial balance or balance sheet through the API, OneWorld accounts require you to specify a subsidiary context for the report. A consolidated trial balance rolls up child subsidiary data through the hierarchy with currency translation at each level. Getting this wrong does not produce an error. It produces wrong numbers, which is worse.

NetSuite also handles tracking dimensions (departments, locations, classes) differently across editions. On OneWorld accounts, departments and locations are scoped to specific subsidiaries, which means your integration needs to validate that a given dimension ID is valid for the subsidiary context of the transaction you are creating.

NetSuite SOAP deprecation and the REST API migration timeline

NetSuite does not have one API. It has at least three: SuiteTalk SOAP (being deprecated), SuiteTalk REST, and SuiteQL (accessed through the REST query endpoint). Each has different strengths and gaps.

SuiteQL is the most capable for read-heavy workloads. It supports JOINs, aggregations, and server-side filtering through SQL-like syntax. The REST Record API is better for individual CRUD operations. And for some operations (generating transaction PDFs, accessing dynamic form metadata), you still need custom SuiteScript RESTlets deployed into the customer's account.

Oracle is actively winding down SOAP. The 2025.2 release is the last planned SOAP endpoint. Starting with 2026.1, no new SOAP endpoints ship by default. By 2028.2, SOAP will be fully removed. Any integration still running on SOAP at that point will stop working. If you have not started your migration, our NetSuite API key guide covers the authentication setup for both REST and OAuth 2.0.

The SOAP deprecation interacts with the OneWorld complexity in a specific way: many older integrations handled subsidiary context through SOAP's search and record operations, where the subsidiary field was just another XML element to include or exclude. Migrating those integrations to REST and SuiteQL means rebuilding the query logic from scratch, and the OneWorld branching has to be redesigned at the same time. You cannot simply swap XML payloads for JSON payloads and call it done.

REST also has known gaps. The subsidiary record itself is read-only through REST (GET only, no POST/PATCH/DELETE). Legacy tax engine features are not exposed through REST at all, which matters because each OneWorld subsidiary can have different tax configurations. SuiteTax is the path forward, but not every NetSuite customer has migrated to it.

What this means for unified API platforms and ERP integrations

If you are a SaaS company building a NetSuite integration in-house, you need to handle all of this yourself. That means runtime feature detection and conditional query routing, plus currency normalization and subsidiary-aware data scoping on top. Add ongoing maintenance as Oracle evolves the API surface, and the effort compounds quickly. This is one of the reasons ERP API integration is consistently cited as the most engineering-intensive category of SaaS connectivity.

If you are using a unified API platform like Apideck, the platform should be handling these differences for you. The value proposition is that you call a single GET /accounting/invoices endpoint and get a normalized response regardless of whether the underlying NetSuite account is Standard or OneWorld, single-currency or multi-currency, using SuiteTax or the legacy tax engine.

The quality of a unified API's NetSuite connector comes down to how well it handles this matrix. A connector that only works against Standard accounts, or only against OneWorld accounts, is not production-ready. The feature detection, query branching, and currency normalization have to work across the full range of NetSuite configurations that exist in the wild.

For Apideck specifically, our NetSuite Accounting API connector handles OneWorld and Standard accounts through automated feature detection at connection time. The SuiteQL queries adapt based on the detected configuration, and the response schema stays consistent regardless of the underlying edition. Subsidiary data surfaces as a standard field when present and is omitted cleanly when it is not.

Practical checklist for NetSuite API integration teams

If you are building or maintaining a NetSuite integration, here is what the OneWorld vs Standard split requires:

Detect OneWorld and multi-currency status at connection time by probing for table availability. Cache those flags and use them for query routing throughout the integration lifecycle.

Maintain parallel SuiteQL query templates for every resource: one with subsidiary JOINs and one without. Do the same for currency JOINs where relevant.

Scope data reads by subsidiary when working with OneWorld accounts. Pulling all data across all subsidiaries without filtering will return a superset that may not match what the customer expects for a given legal entity.

Handle currency fields explicitly. Know the difference between transaction currency, subsidiary base currency, and consolidated reporting currency. Map each to the correct field in your normalized schema.

Test against both editions. If your test environment only has OneWorld enabled, you are missing half the failure modes. Spin up a Standard test account and run your full test suite against it.

Plan for the SOAP sunset. If any part of your NetSuite integration still uses SOAP, the 2028.2 removal deadline is fixed. Build new integrations on REST and SuiteQL with OAuth 2.0 authentication.

Track REST API gaps. Some OneWorld-specific features (subsidiary record writes, legacy tax fields) are not available through REST. Know where you need SuiteScript RESTlets to fill the gaps, and plan for Oracle to close those gaps over time as REST reaches parity.

NetSuite is one of the most widely deployed ERPs in the world, and the OneWorld vs Standard split is one of its most consequential integration variables. Getting this right is the difference between an integration that works for your first three customers and one that works for your next three hundred.

Frequently asked questions

How do I detect whether a NetSuite account is running OneWorld or Standard via the API?

Probe the subsidiary table at connection time using a SuiteQL query like SELECT id FROM subsidiary LIMIT 1. If the query returns results, the account is running OneWorld. If it throws a "Record not found" error, the account is Standard. Cache this result and use it to select the correct query templates for all subsequent API calls.

Does the NetSuite REST API behave differently on OneWorld vs Standard accounts?

Yes. On OneWorld accounts, records like invoices, customers, and vendors carry a subsidiary field, and records like customerSubsidiaryRelationship become available. On Standard accounts, these fields and records do not exist. The subsidiary REST record itself is read-only (GET only). Your integration needs conditional logic to include or exclude subsidiary-related fields depending on the edition.

Can a Standard NetSuite account use multi-currency without upgrading to OneWorld?

Yes. Multi-currency is a separate feature that can be enabled on Standard accounts. When enabled, transactions can be created in foreign currencies and converted to the single base currency at the exchange rate on the transaction date. OneWorld adds the ability for each subsidiary to have its own base currency, which introduces additional currency translation layers for consolidated reporting.

What happens to my NetSuite SOAP integration when Oracle removes SOAP in 2028?

The 2025.2 SOAP endpoint is the last planned release. Starting with 2026.1, no new SOAP endpoints ship. By 2028.2, all SOAP endpoints will be removed and existing SOAP integrations will stop working. Oracle recommends migrating to REST web services with OAuth 2.0 authentication. For OneWorld accounts, this migration also requires rebuilding subsidiary-aware query logic in SuiteQL.

How to Build ERP Extensions: A Developer Guide to NetSuite, SAP, Business Central, Acumatica, and Sage Intacct

Kate Apideck — Mon, 10 Aug 2026 10:23:10 +0000

NetSuite Customization and ERP Extensions: SuiteScript, Business Central AL, SAP BTP, Acumatica C#, and Sage Intacct Platform Services.

Every ERP vendor has its own answer to the same question: how should third-party developers add functionality without breaking upgrades? The answers vary significantly in tooling and language, but the underlying tension is consistent. Custom code that runs inside the ERP core couples tightly to the ERP's release cycle. Custom code that runs outside connects through APIs and is more stable over time.

This post covers the four platforms where this tradeoff plays out most frequently for Banks, Fintechs and vertical SaaS teams.

NetSuite

NetSuite's extension framework is SuiteCloud. The primary development language is SuiteScript 2.1, which is JavaScript-based. Extensions run inside NetSuite's infrastructure under strict resource limits: script execution time is capped and memory ceilings affect batch processing. A SuiteApp that passes sandbox testing can fail in production under real transaction volume.

SuiteScript provides several script types for different contexts. User Event scripts fire on record load, validate, and save. Client Scripts run in the browser and respond to field changes. Suitelets are full server-side pages hosted on NetSuite's domain, accessible via URL and iFrameable into other views. Portlets render as panels on the NetSuite dashboard.

A concrete example: a revenue operations ISV might build a Suitelet that shows a customer's payment history alongside a real-time credit limit recommendation from an external risk model. The Suitelet fetches transaction data via nlapiSearchRecord, calls the external risk API, and renders an HTML table inside the NetSuite interface. Sales reps access it via a button injected into the Customer record through a Client Script. The whole thing deploys as a SuiteApp through SuiteCloud Development Framework (SDF) and can be listed on the SuiteApp Marketplace.

For API access, NetSuite uses Token-Based Authentication (TBA) for machine-to-machine calls and OAuth 2.0 for user-facing apps. SuiteCloud 2026.1 (February 2026) brought REST web services to functional parity with SOAP, which had previously been required for certain advanced operations. For SuiteApps that expose NetSuite data to external systems, REST-first is now a complete option without the SOAP dependency.

Microsoft Dynamics 365 Business Central

Business Central's extension model runs on AL (Application Language), a proprietary language Microsoft introduced when it moved the platform to the cloud. AL is the only supported path for customizing BC logic. You write it in Visual Studio Code with the AL Language extension, publish apps to a sandbox or production tenant, and distribute through Microsoft's AppSource marketplace for cloud deployments.

AL uses an event-based pattern: the framework publishes events at key points in standard business processes, and your extension subscribes to them. Adding fields to a table requires a table extension object; modifying a page requires a page extension. Business logic lives in codeunits. Subscribing to OnAfterPostSalesOrder to trigger a third-party fulfillment workflow is a common pattern, and it's upgrade-safe because extensions can't modify base objects directly, only layer on top of them.

For UI extensions that go beyond field injection, BC offers control add-ins. A control add-in is declared in AL but renders as an iframe hosting JavaScript and HTML. It communicates back to AL via the Microsoft.Dynamics.NAV.InvokeExtensibilityMethod API. A concrete example: an ISV building a logistics product might embed a live shipment tracking map inside the Sales Order page using a control add-in, pulling carrier API data and rendering it as an interactive element alongside the native BC fields. The iframe boundary keeps the JavaScript isolated; the AL callback handles any state updates back to the record.

Microsoft ships BC updates monthly. One practical consequence of the event subscription model is that if Microsoft removes an event between releases, subscriber code fails silently until you test against the next sandbox. Testing each monthly release in a development tenant before it goes live is not optional for customer-facing BC extensions. For the full API authentication flows and endpoint patterns, see our Business Central API integration guide.

Sage Intacct

Sage Intacct splits its extensibility model into two distinct layers. External integrations use Web Services, which moved from its XML-only API to a REST API in general availability as of Intacct's 2025 Release 1 (February 2025). For extensions that live inside the Intacct interface, the tool is Platform Services.

Platform Services lets developers create custom objects (with their own fields and relationships) and build full applications with menus and workflows. Behavior can be injected via JavaScript using the AJAX SDK. A Platform application groups custom objects and navigation menus into a self-contained mini-app inside Intacct. The entire application definition exports as XML, making it portable across Intacct companies.

A practical example: a professional services firm might use Platform Services to build a project milestone tracker. The developer creates a custom object that links to Intacct's native Project and AP Bill objects. When a milestone is approved, a trigger fires an API call to create a vendor bill. The forms and approval workflow live entirely within Platform Services; the bill creation uses merge fields to pull milestone data into the standard AP Bill form.

The AJAX SDK has a notable constraint: Sage Intacct explicitly warns against manipulating the standard Intacct DOM (hiding fields with jQuery, for example). Any UI behavior built against undocumented internal elements breaks when Intacct updates its interface. The AJAX Gateway is the only supported path for page scripts that need to call Intacct's back end. This is a narrower surface than many developers expect going in.

Sage also announced in November 2025 that third-party AI agents can now be embedded in the Sage Copilot interface, with an MCP server built on top of the Intacct REST API. That opens a different category of extension that doesn't require Platform Services at all and may be the easier path for read-heavy use cases.

Acumatica

Acumatica's customization model gives developers more direct access to the ERP's internals than the other three platforms here. Customizations are written in C# and packaged into Customization Projects, which can be exported and deployed across environments. The Customization Project Editor in the Acumatica UI handles screen modifications alongside the C# code.

The pattern: Acumatica's data objects are declared as DAC (Data Access Class) classes in C#. Business logic lives in Graph classes. An extension subclasses the relevant DAC or Graph, adding or overriding fields and methods without touching the base code. To add an insurance expiration date to the Vendor screen, a developer creates a VendorExtension : PXCacheExtension<Vendor> class for the field, and a VendorMaintExtension : PXGraphExtension<VendorMaint> for validation logic. The Customization Project wraps both for deployment.

For UI, Acumatica shipped a finalized Modern UI in TypeScript and HTML as of 2025 R2 (released September 2025). Extensions to existing Acumatica screens now require creating matching .ts and .html files in the extensions folder under the screen directory. As of 2025 R2, screen personalizations can be included directly in Customization Projects, which lets ISVs guarantee consistent layouts across environments during deployment.

A concrete example from an ISV: a construction SaaS company might add a compliance status panel to the Subcontract screen, pulling insurance and license data from an external API. The Graph extension handles the data fetch on screen load, while the TypeScript file renders the panel in the Modern UI. The Customization Project packages both for deployment to client tenants.

One thing to plan for: as of late 2025, ISVs with multiple Customization Projects targeting the same screen have run into conflicts. Acumatica's export-to-development function overwrites files from the development folder, which affects teams managing several products for the same customer. This isn't a blocker, but it requires explicit project management.

SAP

SAP sells two products under the same brand that have almost nothing in common from an extensibility standpoint: Business One (B1), aimed at SMBs, and S/4HANA, aimed at mid-market and enterprise. The toolchain, deployment model, and API surface differ enough that treating them as the same platform is a common mistake for ISVs trying to cover both.

SAP Business One

B1's extension model uses the SDK, which exposes two APIs for different contexts. The DI API (Data Interface API) is a COM-based interface that runs on the B1 client or application server, giving add-ons full access to business objects. The Service Layer is a REST API that runs on HANA-based B1 deployments (9.1 PL09 and later) and is the recommended path for web-based or multi-threaded integrations that don't require the full depth of the DI API. For new integrations, Service Layer is generally simpler; DI API remains necessary when you need objects the Service Layer doesn't yet expose.

For UI extensions inside the B1 web client specifically, SAP added a UI API extension framework using JavaScript, TypeScript, and SAPUI5. Development happens in VS Code with a dedicated plugin and a Chrome/Edge-based Web Client Inspector for debugging. A UI API extension targets a specific view in the web client (defined by a JSON layout file) and uses a JavaScript controller for logic. A concrete example: an ISV might add a custom panel to the Business Partner Detail view that surfaces a customer's credit insurance status from an external provider. The JSON file positions the new UI element; the controller fetches and displays the data when the panel loads.

B1 does not use SAP BTP in the same way S/4HANA does. BTP integration is possible but not the primary extensibility model for B1 partners. Most B1 ISV add-ons still ship as traditional SDK-based packages installed on the B1 server.

SAP S/4HANA

S/4HANA's extensibility model follows SAP's clean core framework, which separates on-stack from side-by-side extensions. On-stack extensions run within S/4HANA itself, written in ABAP Cloud using only publicly released APIs. Side-by-side extensions run on SAP BTP and communicate with S/4HANA through APIs and events.

SAP formalizes this in a four-level compliance model (A through D). Level A extensions use only released, stable APIs on both paths. Level C and D extensions access internal objects and carry explicit upgrade risk. For ISVs building multi-tenant SaaS on S/4HANA, SAP's August 2025 extensibility documentation positions BTP side-by-side as the preferred architecture: it keeps the extension deployment decoupled from the ERP core, so the ISV manages its own release cadence without waiting on SAP upgrade windows.

For UI work on S/4HANA, the options split by deployment model. Key-user extensibility lets non-developers add custom fields to standard Fiori apps without code. Developer extensibility goes further with SAPUI5 adaptation projects built in SAP Business Application Studio, which overlay changes onto existing Fiori apps without modifying their base code. New standalone apps can be built with SAPUI5/Fiori Elements and hosted either on-stack in the Fiori Launchpad or on BTP.

A concrete example for S/4HANA: a manufacturing ISV might build a quality inspection panel embedded alongside the standard Production Order screen. The panel pulls sensor data from an IoT system via a BTP integration, renders a Fiori-based status indicator in the Production Order screen, and writes inspection results back to S/4HANA through an OData service. The application runs on BTP Cloud Foundry, connects to S/4HANA through a communication arrangement, and is distributed to customers through the SAP Store.

The practical difference between B1 and S/4HANA for an ISV covering both: B1 extensions typically ship as on-premise or hosted SDK packages, while S/4HANA extensions for cloud deployments ship as BTP applications certified through the SAP Store. Different distribution model, different technical stack.

What breaks

Each platform has its characteristic failure mode.

In SAP, the failure mode depends on which product you're targeting. For B1, the DI API's COM dependency limits add-ons to Windows and requires the B1 client to be running, which creates problems in web-only or headless integration scenarios. The Service Layer is cleaner but doesn't cover all DI API objects, so gaps force a context switch back to the older interface mid-project. For S/4HANA, the risk is API scope: if an extension needs access to an internal object not covered by a released API, it falls into Level C or D on the clean core model and carries explicit upgrade risk when SAP ships updates.

In Business Central, the risk is event volatility. Microsoft adds and deprecates AL events as the base application evolves across monthly releases. A subscriber function becomes a runtime error if the event it depends on is removed. This makes continuous testing against the next monthly release non-negotiable for any BC extension in active customer use.

In Sage Intacct, the constraint is scope. Platform Services handles custom objects well, but complex UI injection hits the sandbox limits quickly. Scripts that manipulate the standard DOM break on Intacct's quarterly releases without warning, since those changes are outside the supported API surface.

In Acumatica, the Modern UI transition introduced a new class of migration work. ISVs with ASPX-based screen customizations are rebuilding them in TypeScript for the Modern UI. The new extension file structure requires precision, and multi-project conflicts on shared screens require coordination that didn't exist in the older model.

In NetSuite, governor limits are the consistent friction point. The script execution time cap hits Suitelets that make external API calls with variable latency. Scheduled scripts queue behind other jobs in the account. These limits are fixed and don't scale with a customer's transaction volume.

What "embedded" means at the API layer

The phrase "embedded app" has two meanings that frequently get conflated. In the ERP vendor context, an embedded app is one that runs within the ERP's infrastructure and is distributed through its marketplace. In the SaaS product context, an embedded app is a product experience that lives inside a customer's workflow without requiring them to leave your tool.

Both definitions are valid. They address different problems. The ERP vendor meaning matters when you're building for a single ERP and care about the vendor's distribution channel. The SaaS product meaning matters when you're building across ERPs and want your product to function consistently regardless of which ERP the customer runs.

SAP's August 2025 extensibility documentation describes side-by-side on BTP as the preferred path for ISV partners building multi-tenant SaaS, precisely because it decouples deployment and lets the ISV manage its own release cadence. That matches how most SaaS companies want to operate: own the infrastructure and release schedule, treating the ERP as a data source rather than a runtime environment.

Most extension projects eventually hit a point where the two definitions need to coexist. A vertical SaaS product might embed a lightweight UI extension inside NetSuite to surface its own data in context, while the bulk of data integration runs through a normalized API layer that also handles the customer's other accounting systems. The extension provides presence inside the ERP; the API layer provides breadth. Which of those two problems you need to solve first is the decision worth making explicitly before you pick a toolchain.

Building for multiple ERPs

For internal IT teams configuring a single ERP instance, the per-platform toolchain is the only path. For SaaS companies whose product needs to work across these four ERPs, maintaining native extensions per platform becomes an engineering capacity problem. No two of these platforms share a development language or deployment model.

The practical alternative is to build your product's interface outside those frameworks and use APIs for data exchange. Your product handles its own workflows; the ERP handles ERP-native work. For operations that need normalized access to financial data (invoices, customers, and journal entries) across these platforms, a unified accounting API layer collapses the per-platform API work into a single schema.

Native embedded extensions still have a clear role. When your product genuinely needs to live inside the ERP's UI, building a native extension for that specific ERP is the right call. The decision is about scope: if "embedded" means your UI inside a single ERP, native extensions make sense. If "embedded" means your product functioning consistently regardless of which accounting system the customer uses, a normalized API layer is cheaper to maintain long-term.

Most ISV teams end up with a hybrid: lightweight native extensions for presence inside one or two priority ERPs, and a unified API integration for data sync across the rest.

How to Get Your Zoho Books API Key

Kate Apideck — Thu, 06 Aug 2026 14:15:45 +0000

Get your Zoho Books OAuth credentials set up and make your first authenticated API call. This guide covers app registration, client types, scopes, the authorization flow, token management, and the mistakes that cost developers time.

What's Zoho Books?

Zoho Books is Zoho's cloud accounting platform, and it has found its audience in small and mid-sized businesses already inside the Zoho ecosystem. Companies using Zoho CRM, Zoho Projects, or Zoho Inventory that want their accounting in the same stack. It handles invoices, bills, expenses, purchase orders, bank feeds, and tax compliance across a range of countries.

The API is REST-based, returns JSON, and follows familiar patterns. Version 3 is the current release. Every request requires two things: a valid OAuth 2.0 access token and an organization_id parameter. Zoho Books supports multiple organizations under one account, and the API enforces strict separation between them. Before you can touch any other endpoint, you'll need the organization ID from GET /organizations.

Note: Zoho Books doesn't use static API keys. Authentication is handled through OAuth 2.0, which means you'll be working with a Client ID, Client Secret, access tokens, and refresh tokens.

If you're planning to connect Zoho Books to your platform alongside other accounting tools, take a look at Apideck's guide on how to integrate with the Zoho Books API for the fuller picture on data mapping and sync patterns. For a broader view of how accounting APIs compare, the top accounting APIs guide covers Zoho Books alongside the other major platforms.

Prerequisites

A Zoho Books account (any paid plan, or a free trial)
A Zoho account login to access the Developer Console
A redirect URI ready for your application (or use the Self Client option if you're building a server-side script without a public URL)

Step 1: Go to the Zoho Developer Console

Open https://api-console.zoho.com and log in with your Zoho account credentials.

Step 2: Create a New Client

Click GET STARTED (or ADD CLIENT if you've been here before). You'll be asked to choose a client type. The five options are:

Server-based Applications: web apps running on a dedicated server with a redirect URI. This is the right choice for most SaaS integrations.
Client-based Applications: browser-only apps (JavaScript, no web server).
Mobile Applications: iOS/Android apps.
Non-browser Applications: devices without browser support such as smart TVs and printers.
Self Client: standalone server-side scripts or back-end jobs with no redirect URL. Good for testing, internal tooling, or one-off data syncs.

For a production integration, pick Server-based Applications. If you're just getting credentials to test an endpoint, Self Client is faster.

Step 3: Fill in Your Application Details

Once you click Create Now for your chosen client type, fill in the following:

Client Name: the name of your application. Zoho uses this on the consent screen your users see.
Homepage URL: the full URL of your app's homepage (required for server-based apps).
Authorized Redirect URIs: where Zoho sends the authorization code after the user approves access. Use https:// in production. You can add multiple URIs.

Click CREATE.

Step 4: Copy Your Client ID and Client Secret

After creation, your Client ID and Client Secret appear in the Client Secret tab. Copy both and store them securely.

Client ID: public identifier for your app.
Client Secret: keep this private. Don't put it in client-side code, public repos, or browser logs.

Step 5: Choose Your Scopes

Scopes control what your app can read and write. Zoho Books uses a consistent naming pattern:

ZohoBooks.{module}.{permission}

Where permission is CREATE, READ, UPDATE, DELETE, or ALL.

Common modules and their scopes:

Module	Example Scope
Invoices	`ZohoBooks.invoices.READ`
Contacts	`ZohoBooks.contacts.ALL`
Bills	`ZohoBooks.bills.CREATE`
Expenses	`ZohoBooks.expenses.READ`
Banking	`ZohoBooks.banking.READ`
Settings	`ZohoBooks.settings.READ`
Accountants	`ZohoBooks.accountants.READ`

Request the minimum scopes your integration needs. Users see these on the consent screen, and a long list raises friction. ZohoBooks.fullaccess.all exists, but it's overkill for most integrations and looks alarming to end users.

Step 6: Build the Authorization URL

For server-based apps, you'll redirect users to Zoho's authorization endpoint to get a grant token (authorization code). Construct a GET request to:

https://accounts.zoho.com/oauth/v2/auth

With these parameters:

Parameter	Value
`client_id`	Your Client ID
`response_type`	`code`
`redirect_uri`	One of your registered redirect URIs
`scope`	Comma-separated scopes
`access_type`	`offline` (to receive a refresh token)

A full example:

https://accounts.zoho.com/oauth/v2/auth?client_id=1000.YOUR_CLIENT_ID&response_type=code&redirect_uri=https://yourapp.com/callback&scope=ZohoBooks.invoices.CREATE,ZohoBooks.contacts.READ&access_type=offline

After the user approves, Zoho redirects to your callback URL with a code parameter. That's your authorization code.

Region note: If your Zoho Books account is on the EU data center, use accounts.zoho.eu instead of accounts.zoho.com. Same for zoho.in, zoho.com.au, zoho.jp, zoho.ca, zoho.com.cn, zoho.sa, and other regional domains. The authorization URL must match the domain of your user's account.

Step 7: Exchange the Code for Tokens

Hit Zoho's token endpoint with a POST request:

https://accounts.zoho.com/oauth/v2/token

Body parameters:

code=AUTHORIZATION_CODE
client_id=YOUR_CLIENT_ID
client_secret=YOUR_CLIENT_SECRET
redirect_uri=https://yourapp.com/callback
grant_type=authorization_code

A successful response:

{
  "access_token": "1000.abc123...",
  "refresh_token": "1000.def456...",
  "api_domain": "https://www.zohoapis.com",
  "token_type": "Bearer",
  "expires_in": 3600
}

Save both tokens. The api_domain field tells you which regional endpoint to use for subsequent API calls.

Step 8: Make Your First API Call

Pass the access token in the Authorization header:

Authorization: Zoho-oauthtoken YOUR_ACCESS_TOKEN

Start by fetching your organization ID:

curl -X GET 'https://www.zohoapis.com/books/v3/organizations' \
  -H 'Authorization: Zoho-oauthtoken YOUR_ACCESS_TOKEN'

Grab the organization_id from the response. You'll need to append ?organization_id=YOUR_ORG_ID to every subsequent request.

Step 9: Handle Token Refresh

Access tokens expire after one hour. When a call returns a 401, use your refresh token to get a new one:

curl -X POST 'https://accounts.zoho.com/oauth/v2/token' \
  -d 'client_id=YOUR_CLIENT_ID' \
  -d 'client_secret=YOUR_CLIENT_SECRET' \
  -d 'refresh_token=YOUR_REFRESH_TOKEN' \
  -d 'grant_type=refresh_token'

The response gives you a new access token. The refresh token stays the same in this flow. If you lose the refresh token, you'll need to restart the OAuth flow from the authorization URL step.

Self Client: The Shortcut for Server-Side Scripts

If you picked Self Client in Step 2, the flow is different. You don't build an authorization URL or handle redirects. Instead:

On the Client Secret tab, copy your Client ID and Client Secret.
Switch to the Generate Code tab.
Enter your required scopes (comma-separated), pick a time duration for the grant token, add a description, and click Create.
Copy the generated grant token immediately. By default it expires after three minutes, though you can select a longer duration from the dropdown.
Exchange that code for tokens using the same token endpoint from Step 7.

Self Client works well for background jobs, internal tooling, and testing. It's not suitable for multi-user apps where each customer needs to authorize your app against their own Zoho Books organization.

Common Mistakes

Wrong regional domain. Zoho Books is multi-datacenter. If a user's account is on zoho.eu, you need accounts.zoho.eu for auth and www.zohoapis.eu for API calls. You can identify the region from the location parameter returned in Zoho's redirect response after authorization.

Grant token already used or expired. Authorization codes are single-use. For server-based apps, the grant token expires after two minutes. For Self Client, the default is three minutes (though you can extend this when generating the token). If you try to exchange one that's been used or has expired, you'll get invalid_code. Generate a fresh code and exchange it right away.

Missing organization_id. Every API endpoint requires ?organization_id=YOUR_ORG_ID. Leaving it out returns a 400 error. Call GET /organizations first and cache the value.

Redirect URI mismatch. The redirect URI in your authorization request must exactly match one registered in the Developer Console. A trailing slash difference, http vs https, or a subdomain variation will return an error.

No refresh token. If you called the authorization endpoint with access_type=online (or omitted it, since online is the default), you won't receive a refresh token. Once the access token expires, users have to re-authorize. For production integrations, always use access_type=offline. If you need a new refresh token after the first authorization, add prompt=consent to force the consent screen again.

Rate Limits

Zoho Books has some of the tighter rate limits among major accounting APIs:

Per-minute: 100 requests per minute per organization (error code 44 on breach)
Per-day: varies by plan
- Free: 1,000 requests/day
- Standard: 2,000 requests/day
- Professional: 5,000 requests/day
- Premium, Elite, and Ultimate: 10,000 requests/day
Concurrent: 5 concurrent calls for Free plans, 10 concurrent calls (soft limit) for paid plans (error code 1070 when exceeded)

The daily limit is shared across all integrations connected to the same organization. If your customer uses other Zoho-connected tools, they're drawing from the same pool. Build exponential backoff into your 429 handling.

Connecting Through Apideck

If Zoho Books is one of several accounting platforms you need to support, building a separate direct integration for each one gets expensive quickly. Apideck's Zoho Books connector connects through a unified accounting API alongside QuickBooks, Xero, Sage, NetSuite, and 30+ other platforms. Authentication, token refresh, rate limit handling, and data normalization are managed at the platform level.

To configure the connector, open the Apideck dashboard, go to Configuration > Connectors, and select Zoho Books under the Accounting API. You'll see two credential options: use Apideck's shared credentials for quick testing, or enter your own Client ID and Client Secret from the steps above for production use.

Once you've entered your credentials and saved, click Authorize to kick off the OAuth flow. After your users connect their Zoho Books account, the Organization ID field populates automatically.

The scopes panel lets you control exactly which Zoho Books resources your connector can access. You can select individual scopes per module (contacts, invoices, bills, and so on) rather than granting full access. The Virtual Webhooks section beneath it shows which resources Apideck will poll for updates, with a default 24-hour sync cycle that you can adjust per resource.

Ready to connect to Zoho Books and 30+ other accounting platforms through a single API? Get started for free.

How to integrate with the FreeAgent API

Kate Apideck — Tue, 04 Aug 2026 09:19:38 +0000

FreeAgent is one of the most popular accounting platforms in the United Kingdom. It serves freelancers and small businesses with invoicing, expense tracking, Self Assessment tax returns, payroll, and MTD-compatible VAT filing. NatWest Group acquired the company in 2018, and it remains a common integration target for software that touches UK financial data.

This guide covers what you need to know to integrate with the FreeAgent API, from authentication and available endpoints to rate limits, pagination, and the specific challenges that make this integration more involved than the documentation suggests. If you want to skip the complexity of building a direct integration, Apideck's FreeAgent connector handles authentication, token refresh, and data normalization through a unified Accounting API.

What FreeAgent covers

FreeAgent targets a specific segment of the UK market: self-employed professionals, freelancers, and small limited companies. The platform handles:

Invoicing and estimates
Expense claims and receipt capture
Bank account connections and reconciliation
Self Assessment tax return filing
VAT returns with Making Tax Digital compliance
Payroll for small teams
Project and time tracking
Multi-currency support

The platform's tight focus on UK tax requirements makes it essential for software serving British freelancers and small businesses. If your customers use FreeAgent, they expect their data to flow into your application without manual exports.

API overview

FreeAgent offers two separate API products, and this distinction matters for how you architect your integration.

The Company API is for direct FreeAgent users: freelancers and small businesses managing their own accounting. This is the standard integration path for most applications.

The Accountancy Practice API is for accounting firms and bookkeepers who manage multiple client accounts through FreeAgent's Practice Dashboard. This requires a separate app registration, a different OAuth flow, and client-specific subdomains in request headers.

For a SaaS product that serves both direct business users and accounting firms, this means building and maintaining two distinct integration paths.

Both APIs are REST-based and support JSON and XML responses. The base URLs are:

Production: https://api.freeagent.com/v2
Sandbox: https://api.sandbox.freeagent.com/v2

The sandbox environment lets you test your integration without affecting live data. FreeAgent provides temporary sandbox accounts through their developer portal for this purpose.

Authentication

FreeAgent uses OAuth 2.0 with the authorization code flow. To get started:

Create an account at the FreeAgent Developer Dashboard
Register a new application to receive your OAuth Client ID and Client Secret
Specify which access level your application requires (more on this below)

The authorization endpoint is:

https://api.freeagent.com/v2/approve_app

The token endpoint is:

https://api.freeagent.com/v2/token_endpoint

A basic token exchange looks like this:

curl -X POST https://api.freeagent.com/v2/token_endpoint \
  -d "client_id=YOUR_CLIENT_ID" \
  -d "client_secret=YOUR_CLIENT_SECRET" \
  -d "grant_type=authorization_code" \
  -d "code=AUTH_CODE" \
  -d "redirect_uri=YOUR_REDIRECT_URI"

Access tokens expire after one hour. Refresh tokens are long-lived (approximately 20 years according to the API response), so you can maintain persistent access without requiring users to re-authenticate.

Access levels

FreeAgent uses a numeric access level system (0 through 8) that controls which resources your app can read or write. When you register your application, you need to specify the access level you require. Each API resource has a minimum required level, and requesting a higher level than necessary will likely slow down your app approval.

Review the documentation to determine the minimum access level that covers your use case. If you only need to read invoices and contacts, you don't need the same permissions as an app that manages payroll.

Key endpoints

The Company API covers the core accounting resources you'd expect:

/v2/contacts for customers and suppliers
/v2/invoices for sales invoices
/v2/bills for purchase invoices
/v2/expenses for expense claims
/v2/bank_accounts for connected bank accounts
/v2/bank_transactions for bank transaction data
/v2/projects for project management
/v2/tasks for time tracking
/v2/users for user accounts
/v2/company for company settings
/v2/categories for expense categories
/v2/tax_rates for VAT rates
/v2/journal_entries for manual journal entries
/v2/payroll_profiles and /v2/payslips for payroll data

The API supports standard CRUD operations on most resources. Each endpoint is documented in the FreeAgent API documentation.

Rate limits

FreeAgent enforces the following rate limits:

120 requests per minute per user
3,600 requests per hour per user
15 token refreshes per minute per user

These limits reset at the start of every hour or minute. For Accountancy Practice API users, rate limits apply per client subdomain rather than to the practice as a whole.

When you hit a rate limit, the API returns a 429 response with a Retry-After header indicating how long to wait:

HTTP/1.1 429 Too Many Requests
Retry-After: 60

The 120 requests per minute limit is generous for most use cases. However, the 15 token refreshes per minute limit creates a specific bottleneck for multi-tenant applications. If you're running a SaaS product with many customers and you trigger concurrent token refreshes during a scheduled sync, you can exhaust this limit before pulling any actual data. You'll need to implement token refresh queuing or stagger sync schedules across your customer base.

FreeAgent provides a testing header X-RateLimit-Test that artificially lowers the sandbox rate limit to 5 requests per minute, letting you verify your backoff strategy before hitting production limits.

Pagination

API requests that return multiple items are paginated with a default of 25 items per page and a maximum of 100 items per page.

GET https://api.freeagent.com/v2/invoices?page=2&per_page=50

Pagination metadata comes in headers rather than the response body:

The Link header contains URLs for prev, next, first, and last pages
The X-Total-Count header contains the total number of items

The 25-item default is lower than most accounting APIs. If you're syncing large datasets, you'll want to set per_page=100 and implement proper pagination handling to avoid missing records.

Working with contacts

Creating a contact requires minimal data:

curl -X POST https://api.freeagent.com/v2/contacts \
  -H "Authorization: Bearer YOUR_ACCESS_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "contact": {
      "first_name": "Jane",
      "last_name": "Smith",
      "email": "jane@example.com",
      "organisation_name": "Smith Consulting"
    }
  }'

A successful creation returns a 201 status with the created contact object, including the FreeAgent URL identifier you'll need for subsequent operations.

Integration challenges

Beyond the two-API-product architecture and rate limits, several characteristics make FreeAgent integrations more complex than they initially appear.

No webhooks. The standard FreeAgent API doesn't support webhooks for real-time notifications. You'll need to poll for changes, which means designing an efficient sync strategy that respects rate limits while keeping data reasonably current. This is a meaningful limitation for applications that need near-real-time data.

UK-specific data models. FreeAgent's data structures reflect UK accounting conventions and tax requirements. VAT handling, Self Assessment categories, and MTD-specific fields may not map cleanly to more generic accounting schemas. If you're building a multi-country application, you'll need transformation logic specific to FreeAgent's UK-centric model.

Documentation in context. While the API documentation is available through the developer portal, some details only become clear through trial and error. Error messages are generally helpful, but the sandbox environment is essential for understanding how the API actually behaves before you deploy to production.

Scaling beyond FreeAgent

FreeAgent covers the UK freelancer and small business market well, but most B2B applications need to integrate with multiple accounting platforms. Your UK customers use FreeAgent, your US customers use QuickBooks, your Dutch customers use SnelStart, and your Australian customers use Xero.

Building and maintaining direct integrations to each platform means handling different authentication flows, different data models, different rate limits, and different error handling for every connector. Each integration requires its own development time and ongoing maintenance as APIs change.

A unified API gives you one integration point and one data schema across all of them. Instead of managing FreeAgent's token refresh limits, QuickBooks' OAuth flow, and Xero's pagination separately, you write against a single normalized Accounting API and let the platform handle the connector-specific complexity.

With Apideck, listing invoices from FreeAgent looks like this:

import { Apideck } from '@apideck/node'

const apideck = new Apideck({
  apiKey: process.env.APIDECK_API_KEY,
  appId: process.env.APIDECK_APP_ID,
  consumerId: 'user-123'
})

const { data } = await apideck.accounting.invoicesAll({
  serviceId: 'freeagent'
})

The same code structure works for QuickBooks, Sage, Xero, and every other accounting connector in the platform.

Create a free Apideck account to get started.

How to Integrate with the Zoho Books API

Kate Apideck — Mon, 03 Aug 2026 12:27:56 +0000

Zoho Books is a cloud-based accounting platform popular with small and mid-sized businesses, particularly those already embedded in the Zoho ecosystem. If your product serves finance teams, you'll eventually get a request to pull invoice data from Zoho Books or push expense records into it.

This guide covers the technical work involved: authentication, key endpoints, rate limits, data mapping, and the common pitfalls that trip up first-time integrators. If you want to skip the direct integration work, Apideck's Zoho Books connector handles the plumbing through a unified accounting API.

What the Zoho Books API offers

The Zoho Books API is a REST API that returns JSON responses. Version 3 is the current release and covers the full range of accounting operations: contacts, invoices, expenses, bills, bank transactions, purchase orders, and sales orders.

Every API request requires two things: an OAuth 2.0 access token and an organization_id parameter. Zoho Books supports multiple organizations under a single account, and the API enforces strict separation between them. You'll need to retrieve the organization ID first (via GET /organizations) before calling any other endpoint.

Base URL: https://www.zohoapis.com/books/v3/

One complication: Zoho operates regional data centers with distinct API domains: .com, .eu, .in, .com.au, .jp, .ca, .sa (Saudi Arabia), and .uk. The API domain must match where the user's Zoho Books account is hosted. A customer on zoho.eu needs API calls to zohoapis.eu. Getting this wrong produces authentication errors that look like token problems.

The modern approach is to detect the data center automatically during OAuth. When you make the initial authorization request to accounts.zoho.com, the response includes a location parameter indicating the user's data center. You can also call https://accounts.zoho.com/oauth/serverinfo to get the full mapping of location codes to API domains. This beats asking users to identify their region manually.

Authentication setup

Zoho uses OAuth 2.0 with the authorization code grant type. The flow works like most OAuth implementations, with a few Zoho-specific details.

Register your application

Go to the Zoho Developer Console and create a new client. You'll choose between two client types:

Web-based: Standard OAuth flow with redirect URIs. Use this for applications where users authenticate through a browser.
Self-client: Server-to-server authentication. Generates tokens without user interaction after the initial setup. Useful for backend services and scheduled syncs.

Registration gives you a client ID and client secret.

Implement the authorization flow

For web-based clients, redirect users to Zoho's authorization endpoint:

GET https://accounts.zoho.com/oauth/v2/auth
  ?response_type=code
  &client_id={your_client_id}
  &scope=ZohoBooks.invoices.READ,ZohoBooks.contacts.READ
  &redirect_uri={your_redirect_uri}
  &access_type=offline

The access_type=offline parameter is important. Without it, you won't receive a refresh token, and your integration will break after an hour when the access token expires.

After the user authorizes, Zoho redirects to your URI with an authorization code. Exchange it for tokens within two minutes:

POST https://accounts.zoho.com/oauth/v2/token
  ?code={authorization_code}
  &client_id={your_client_id}
  &client_secret={your_client_secret}
  &redirect_uri={your_redirect_uri}
  &grant_type=authorization_code

Manage token lifecycle

Access tokens expire after one hour. Refresh tokens don't expire unless revoked, and you can reuse the same refresh token to generate new access tokens repeatedly. Store the refresh token securely and use it to generate new access tokens before they expire:

POST https://accounts.zoho.com/oauth/v2/token
  ?refresh_token={refresh_token}
  &client_id={your_client_id}
  &client_secret={your_client_secret}
  &grant_type=refresh_token

Zoho's scopes are granular. Instead of broad permissions like "accounting:read", you request specific capabilities: ZohoBooks.invoices.CREATE, ZohoBooks.contacts.READ, ZohoBooks.expenses.UPDATE. Request only what you need. The full scope list covers contacts, settings, estimates, invoices, customer payments, credit notes, projects, expenses, sales orders, purchase orders, bills, debit notes, vendor payments, banking, and accountant operations.

Key endpoints

Category	Endpoint	Common operations
Contacts	`/contacts`	Create and manage customers and vendors
Invoices	`/invoices`	Create, send, and track invoices
Expenses	`/expenses`	Record and categorize expenses
Bills	`/bills`	Manage accounts payable
Banking	`/bankaccounts`, `/banktransactions`	Bank feeds and reconciliation
Recurring	`/recurringinvoices`, `/recurringexpenses`	Subscription billing and repeat expenses
Orders	`/salesorder`, `/purchaseorder`	Sales and purchase order management

A few endpoints worth noting:

POST /invoices/fromsalesorder creates an invoice directly from a sales order, which saves a round trip if you're building order-to-cash workflows.

POST /invoices/email and POST /invoices/paymentreminder handle customer communication without leaving the API.

GET /organizations returns all organizations the authenticated user can access, along with currency settings, fiscal year configuration, and time zone. Call this first to get the organization_id you'll need for everything else.

Data mapping considerations

Zoho Books uses its own data model, which won't map 1:1 to other accounting systems. If you're building a multi-platform integration, here are the fields that cause the most trouble.

Contacts

Zoho combines customers and vendors into a single contacts endpoint, distinguished by contact_type. The contact_name field has a 200-character limit. Company information goes in company_name, not the contact name. Billing and shipping addresses are nested objects with their own field structure.

Invoices

Tax handling is line-item based. Each line item can have its own tax rate, and the tax configuration at the header level must match the line items. Mismatches produce validation errors that aren't always obvious from the error message.

Line items use item_id for products from your Zoho inventory or can be created as custom items with name, description, rate, and quantity.

Custom fields

Most resources support custom fields through a custom_fields array. Each custom field requires a customfield_id (retrieved from the organization settings API) and a value. Custom field IDs are organization-specific, so don't hardcode them.

Rate limits

Zoho Books has some of the most restrictive rate limits among major accounting APIs. Plan your integration accordingly.

Per-minute limit: 100 requests per minute per organization. Exceeding this returns HTTP 429 with error code 44.

Daily limits vary by plan:

Free: 1,000 calls/day
Standard: 2,000 calls/day
Professional: 5,000 calls/day
Premium/Elite/Ultimate: 10,000 calls/day

Exceeding daily limits returns HTTP 429 with error code 45.

Concurrent limit: Roughly 10 simultaneous requests per organization. HTTP 429 with error code 1070 indicates you've hit this ceiling.

The daily limit is shared across all API consumers for that organization. If your customer uses other Zoho integrations or third-party tools that call the API, those count against the same quota. This creates situations where your integration fails because something else exhausted the limit.

Build in exponential backoff for 429 responses. For bulk operations, consider batching and spreading requests across longer time windows.

Error handling

Zoho Books returns HTTP status codes with JSON error bodies:

{
  "code": 44,
  "message": "For security reasons your account has been blocked as you have exceeded the maximum number of requests per minute."
}

Common error codes:

0: Success
44: Per-minute rate limit exceeded
45: Daily rate limit exceeded
1070: Concurrent request limit exceeded
1000-1099: Various validation and business logic errors

Log the full error response, not just the HTTP status. The code field often contains more actionable information than the status code alone.

Testing your integration

Zoho Books doesn't offer a dedicated sandbox environment. You have two options:

Create a test organization: Set up a separate Zoho Books organization for development. This uses real API calls against real infrastructure but keeps test data isolated from production.
Use a trial account: Zoho offers free trials that provide API access. Useful for testing, but trial limitations may not reflect production behavior.

Test these scenarios specifically:

Token refresh: Let an access token expire and verify your refresh logic works
Rate limit handling: Intentionally exceed limits and confirm your backoff implementation
Multi-organization: If your users might have multiple Zoho Books organizations, test the organization selection flow
Regional domains: Test with accounts on different Zoho data centers if your customer base is international

Webhooks and real-time sync

Zoho Books supports outgoing webhooks for real-time notifications. You can configure webhooks in Zoho Books to fire when events occur (invoices created, payments received, contacts updated, etc.), sending HTTP POST requests to your endpoint with the event payload. This eliminates the need for constant polling.

To set up webhooks, navigate to Settings > Automation > Webhooks in the Zoho Books UI and define the trigger events and destination URL. You can also receive incoming webhooks from external systems to create or update records in Zoho Books.

For scenarios where webhooks aren't practical, you can poll endpoints periodically using the last_modified_time field on most resources to filter for recent updates. But webhooks are the cleaner approach for near-real-time sync requirements.

Connecting through a unified API

Building a direct Zoho Books integration makes sense if Zoho is your only target. But most B2B applications need to support multiple accounting platforms. Your QuickBooks customers expect the same sync features as your Zoho customers, and your Xero customers will ask for parity next quarter.

Direct integrations mean duplicating the authentication, data mapping, error handling, and maintenance work for each platform. A unified accounting API abstracts those differences behind a single interface.

Apideck's accounting API normalizes Zoho Books alongside QuickBooks, Xero, Sage, NetSuite, and 45+ other platforms. One integration gives your customers their choice of accounting software. Authentication, webhooks, and rate limit management are handled at the platform level.

This approach trades some Zoho-specific customization for dramatically reduced integration scope. If you're building invoice automation or expense sync features, the normalized data model covers the common operations without requiring platform-specific code paths.

Getting started

If you're building direct to Zoho Books:

Register at the Zoho Developer Console
Implement OAuth with offline access
Detect data centers automatically via the location parameter in OAuth responses
Store organization IDs and regional domains per customer
Build rate limit handling from day one

If you want to support multiple accounting platforms:

Sign up for an Apideck account
Enable the Zoho Books connector
Use the unified accounting API for contacts, invoices, and expenses

FAQ

Does Zoho Books have a sandbox environment?

No. Test against a separate organization or trial account to avoid polluting production data.

How do I handle customers on different Zoho data centers?

Detect the data center automatically during OAuth. The authorization response includes a location parameter (e.g., us, eu, in). Use https://accounts.zoho.com/oauth/serverinfo to map location codes to the correct API domains. Store the data center domain alongside the OAuth tokens for each customer.

Why am I getting "invalid_code" when exchanging the authorization code?

Authorization codes expire after two minutes and can only be used once. If your token exchange is slow or you retry a failed request with the same code, you'll hit this error.

Can I increase the API rate limits?

The limits are tied to the Zoho Books subscription plan. Your customer would need to upgrade to a higher tier for increased limits. There's no separate API-specific upgrade path.

Does Zoho Books support webhooks?

Yes. Zoho Books supports outgoing webhooks that notify your application when events occur. Configure them through Settings > Automation > Webhooks in the Zoho Books interface. You can trigger webhooks on invoice creation, payment receipt, contact updates, and other events.

How to Create a Stripe App

Kate Apideck — Fri, 31 Jul 2026 12:28:23 +0000

Stripe handles payments for millions of businesses, from startups to enterprises. If you're building an integration that syncs financial data from Stripe, you'll need to create a Stripe App to obtain OAuth credentials. This guide walks through creating a Stripe App and retrieving the credentials required to connect Stripe to other platforms.

For a unified approach to accounting integrations, check out the Apideck Stripe connector, which lets you pull Stripe data alongside 30+ other accounting platforms through a single API.

What is Stripe?

Stripe is a payment processing platform that enables businesses to accept online payments and manage recurring billing. Beyond payment processing, Stripe exposes financial data through its API, including transactions and customer records. For accounting integrations, this data is typically accessed via Stripe Apps using OAuth rather than raw API keys.

Prerequisites

Before you start, make sure you have:

A Stripe account
An Apideck account
Node.js installed and up to date
Stripe CLI version 1.12.4 or newer

Creating a Stripe App

Apideck's Stripe connector uses the Stripe Apps platform for OAuth authentication. For the complete walkthrough, see Apideck's OAuth Credentials Guide. Here's a summary of the key steps:

Install the Stripe CLI if you haven't already.
Run stripe login to authenticate with your Stripe account.
Verify your CLI version is 1.12.4 or newer with stripe version.
Install the Stripe Apps plugin: stripe plugin install apps
Verify the apps plugin version (should be 1.5.12 or later): stripe apps -v
Create a new app: stripe apps create apideck-integration
Follow the prompts for your app ID and display name.
Navigate to your app directory: cd apideck-integration
Upload your app: stripe apps upload

Once uploaded, you can access your app's OAuth credentials in the Stripe Dashboard under Developers > Created apps.

Getting Your Client ID and Client Secret

After uploading your Stripe App:

In the Stripe Dashboard, go to Developers > Created apps.
Click your app to open its details page.
Open the External test/live tab.
Your Client ID is displayed here (starts with ca_).
Generate a Client Secret if you haven't already. Store this securely as it won't be shown again.

Setting Up the Redirect URI

OAuth requires a redirect URI where users return after authorizing the connection. For Stripe Apps, you configure this in your app manifest file (stripe-app.json):

{
  "allowed_redirect_uris": [
    "https://unify.apideck.com/vault/callback"
  ]
}

You can find a complete working example in the apideck-samples/stripe-app public repo.

After updating your manifest, run stripe apps upload to apply the changes. Without the correct redirect URI, the OAuth flow will fail with an invalid redirect error.

Finding Your Channel Link ID

Apideck's Stripe connector requires a Channel Link ID, which identifies your app's OAuth install link.

In the Stripe Dashboard, go to Developers > Created apps.
Click your app to open its details page.
Open the External test/live tab.
Locate the OAuth install link in the Test OAuth section.
The Channel Link ID is part of this URL, formatted as chnlink_xxxxx.

Copy this value for use in the Apideck connector configuration.

About Stripe Account IDs

When users connect their Stripe accounts through your integration, they may need to provide their Stripe Account ID. This is different from the OAuth credentials you just created. The Account ID:

Starts with acct_
Is found in the Stripe Dashboard under Settings > Account details
Identifies the specific Stripe account being connected

This ID is used by your integration to access bank account information and other account-specific data.

Common Mistakes

Wrong redirect URI: The most frequent OAuth error. Double-check that the redirect URI in your Stripe App matches exactly what your integration expects. Trailing slashes matter.

Mixing test and live credentials: Stripe maintains separate credentials for test mode and live mode. If your integration isn't seeing real data, verify you're using live credentials, not test ones.

Missing permissions: If your integration can't access certain data, check whether you've enabled the required permissions in your app manifest. The stripe_apps scope is used for OAuth authentication, but actual data access depends on the permissions you've defined.

Client Secret exposure: Never commit your Client Secret to version control or expose it in client-side code. Treat it like a password.

Rate Limits

Stripe's API uses rate limiting to ensure stability. The default rate limit is 100 operations per second in live mode and 25 operations per second in sandbox mode. Some endpoints have stricter limits. If you hit rate limits, Stripe returns a 429 Too Many Requests response. The Stripe-Rate-Limited-Reason header indicates which limit was exceeded.

For high-volume integrations, consider implementing exponential backoff and caching frequently accessed data.

Connecting Stripe via Apideck

Apideck's unified Accounting API lets you connect to Stripe alongside platforms like QuickBooks and Xero through a single integration. Once you have your Stripe App credentials, configuring the connector takes a few minutes.

Admin Configuration

Log into your Apideck account and navigate to the Configuration page.
Under Unified APIs, select Accounting.
Find the Stripe connector and click to expand its settings.

Enter your Client ID and Client Secret from your Stripe App.
Scroll down to the Scopes section and enable stripe_apps for full access to account data.
In the OAuth Configuration section, enter your Channel Link ID (format: chnlink_xxxxx).

Click Save settings.

User Connection Flow

Once admin configuration is complete, your users can connect their Stripe accounts through Apideck Vault:

When a user initiates the connection, they'll see the Stripe authorization modal.
The user enters their Stripe Account ID (found in their Stripe Dashboard under Settings > Account details).
They click Authorize to complete the OAuth flow.

After authorization, you can pull financial data from Stripe through Apideck's unified Accounting API.

Ready to connect to Stripe and 45+ other accounting platforms through a single API? Get started for free.

How to Get Your Stripe API Key

Kate Apideck — Wed, 29 Jul 2026 13:55:08 +0000

Stripe provides API keys that let you integrate payment processing, billing, and financial data into your applications. This guide walks through finding and creating API keys in the Stripe Dashboard.

For a unified approach to accounting integrations, check out the Apideck Stripe connector, which lets you pull Stripe data alongside 30+ other accounting platforms through a single API.

What is Stripe?

Stripe is a payment processing platform that enables businesses to accept online payments and manage recurring billing. Through its API, you can access financial data including customers, invoices, payments, subscriptions, and transaction history.

Prerequisites

Before you start, make sure you have:

A Stripe account
Admin or developer access to the Stripe Dashboard

Finding Your API Keys

Stripe provides two types of API keys: publishable keys (for client-side code) and secret keys (for server-side code). Each type has both test and live versions.

Log into the Stripe Dashboard.
Click Developers in the left sidebar.
Select API keys from the menu.

Your publishable key (pk_live_ or pk_test_) and secret key (sk_live_ or sk_test_) are displayed here. In test mode, you can reveal the secret key as many times as needed. In live mode, you can only reveal a secret key once, so copy and store it immediately.

Creating a Restricted API Key

For better security, you can create restricted keys that limit access to specific resources. This is recommended when integrating with third-party services.

In the API keys page, click Create restricted key.
Give the key a descriptive name.
Set permissions for each resource type. For read-only integrations, select Read for the resources you need access to.
Click Create key.

Common permissions for accounting integrations include read access to: Customers, Charges, PaymentIntents, Invoices, Subscriptions, and Products.

Test Mode vs Live Mode

Stripe maintains separate environments for testing and production:

Test mode uses keys starting with pk_test_ and sk_test_. No real money is processed.
Live mode uses keys starting with pk_live_ and sk_live_. Real transactions occur.

Toggle between modes using the Test mode switch in the Dashboard. Make sure you're using the correct keys for your environment.

Common Mistakes

Exposing your secret key: Never include your secret key in client-side code, commit it to version control, or share it publicly. Treat it like a password.

Using test keys in production: If your integration isn't processing real payments, verify you're using live mode keys, not test keys.

Overly permissive keys: Use restricted keys with minimal permissions rather than your main secret key. This limits potential damage if a key is compromised.

Forgetting to rotate keys: If you suspect a key has been exposed, roll it immediately from the API keys page.

Rate Limits

Stripe's API enforces rate limits to ensure platform stability. The default limit for most endpoints is 25 requests per second, though Stripe may increase this for accounts with higher usage. Some endpoints have stricter limits (the Search API and Files API are limited to 20 operations per second). Test mode has lower limits than live mode. If you exceed these limits, Stripe returns a 429 Too Many Requests response.

For high-volume integrations, implement exponential backoff and cache frequently accessed data.

Connecting Stripe via Apideck

Apideck's unified Accounting API lets you connect to Stripe alongside platforms like QuickBooks and Sage through a single integration.

Note that Apideck's Stripe connector uses OAuth rather than standard API keys. You'll need to create a Stripe App first to get your Client ID, Client Secret, and Channel Link ID. See our How to Create a Stripe App guide for the full walkthrough.

Configuring the Connector

With your Stripe App credentials ready, open the Apideck dashboard and navigate to Configuration > Accounting > Stripe.

Enter your Client ID and Client Secret, then scroll down to configure scopes and add your Channel Link ID.

What Your Users See

When your users connect their Stripe account through Vault, they'll be prompted for their Stripe Account ID (found under Settings > Account details in Stripe, starts with acct_).

After authorization, Stripe data flows through Apideck's unified API alongside your other accounting integrations.

Ready to connect to Stripe and 45+ other accounting platforms through a single API? Get started for free.

An introduction to the Stripe APIs: A Developer's Guide to Every API Surface

Kate Apideck — Mon, 27 Jul 2026 13:53:38 +0000

Stripe processed $1.9 trillion in total payment volume in 2025. More than 300,000 businesses use Stripe Billing alone, managing close to 200 million active subscriptions. When your platform needs to connect to where money actually flows, Stripe is usually the first integration your customers request.

But Stripe's API surface is large. Over 500 endpoints across two namespaces (v1 and v2), covering one-time card charges, multi-party marketplace payouts, subscription billing, fraud detection, card issuing, treasury services, and tax compliance. Picking the right API for your use case saves you weeks. This guide covers each major surface, when to reach for it, and how the pieces connect.

The Core Payments API

Most Stripe integrations start here. The central object is the PaymentIntent, which represents a single attempt to collect money from a customer. You create one with an amount and currency, attach a payment method, confirm it, and Stripe handles card network routing, 3D Secure authentication, retry logic, and settlement.

curl https://api.stripe.com/v1/payment_intents \
  -u sk_test_your_key: \
  -d amount=2000 \
  -d currency=usd \
  -d payment_method=pm_card_visa \
  -d confirm=true

The Payments API supports over 100 payment methods across 135+ currencies: cards, bank debits (ACH, SEPA), wallets (Apple Pay, Google Pay), and buy-now-pay-later options like Klarna and Affirm. For most SaaS platforms and e-commerce businesses, this is the only API you need to accept money.

Related endpoints include SetupIntents (saving payment methods without charging) and Refunds. There is also the older Charges API, which still works but lacks support for SCA requirements in Europe and newer payment methods. If you are starting a new integration, use PaymentIntents. Stripe has been steering developers toward this model since 2019, and their llms.txt instructions section now explicitly tells AI coding assistants to do the same.

Stripe Billing: Subscriptions and Invoices

Stripe Billing is the revenue engine for SaaS companies. It manages the full lifecycle of recurring payments: creating subscriptions, generating invoices, handling prorations on plan changes, managing trials, and collecting failed payments automatically.

The core objects are Product, Price, Subscription, and Invoice. A Product describes what you sell. A Price attaches a billing interval and amount to that product. A Subscription ties a customer to one or more prices and tells Stripe when to bill them. Invoices are generated automatically at each billing cycle.

The complexity Billing handles would take months to build yourself. When a customer on a $100/month plan upgrades to $200/month halfway through a billing cycle, Stripe calculates the prorated amount, generates the right invoice line items, and charges the difference. Subscription schedules let you model phased pricing, free trials that convert to paid plans, and multi-interval billing where different line items renew on different cadences.

Usage-based billing is another major capability. Stripe Billing supports metered pricing where you report usage throughout a billing period and Stripe calculates the total at invoice time. This model is common among AI and infrastructure companies that charge per API call, per token, or per compute hour. Anthropic, OpenAI, Cursor, and Midjourney all run on Stripe Billing.

At Stripe Sessions 2025, the company announced Scripts and Workflows: two extensibility primitives that turn Billing into a programmable revenue engine. Scripts let you inject custom business logic into specific API objects. Workflows let you orchestrate multi-step flows across Stripe products using conditional logic. These signal that Stripe views Billing as a platform in its own right.

For teams that need to sync Stripe Billing data with accounting platforms (QuickBooks, Xero, NetSuite, Sage), Apideck's Stripe connector pulls subscription, invoice, and payment data from Stripe through Apideck's Unified Accounting API alongside 45+ other accounting connectors, using a single integration.

Connect: Platforms and Marketplaces

Connect is Stripe's API for multi-party money movement. If your platform collects payments from customers and splits the proceeds among sellers, service providers, or other third parties, Connect handles funds flow, onboarding, compliance, and payouts.

Accounts V2: the recommended path for new platforms

In December 2025, Stripe shipped the Accounts V2 API, which is now the recommended integration path for new Connect platforms. The core improvement: a single Account object that can be configured as a merchant (to accept payments), a customer (to be charged by your platform), and a recipient (to receive transfers). In the V1 API, representing the same business as both a connected account and a customer required creating and managing separate Account and Customer objects with no built-in relationship between them.

Accounts V2 provides three key advantages:

Flexible account configurations. You assign merchant, customer, or recipient configurations to an Account to enable different capabilities. Adding a configuration later does not require re-collecting identity requirements that were already provided.
Centralized identity data. KYC information is shared across configurations. A connected account that also subscribes to your platform's SaaS product does not need to verify their identity twice.
A single API for connected accounts and customers. Any API endpoint that accepts a customer parameter also accepts a customer_account parameter, so you can use a configured Account in place of a Customer object when creating subscriptions, payment intents, or setup intents.

A V2 account creation call looks like this:

curl -X POST https://api.stripe.com/v2/core/accounts \
  -H "Authorization: Bearer sk_test_your_key" \
  -H "Stripe-Version: 2025-12-15.clover" \
  --json '{
    "contact_email": "seller@example.com",
    "display_name": "Example Seller",
    "identity": {
        "country": "us",
        "entity_type": "company"
    },
    "configuration": {
        "merchant": {
            "capabilities": {
                "card_payments": { "requested": true }
            }
        }
    }
  }'

The V1 Accounts and Customers APIs are still fully supported. Stripe does not plan to remove them. You can also use the V2 API to manage accounts that were originally created with V1, including adding the customer configuration to existing V1 accounts. One caveat: if your platform uses OAuth to authenticate with connected accounts, continue using the V1 APIs for now.

Charge models and funds flow

Whether you use V1 or V2, Connect's charge models remain the same. Each seller or provider on your platform gets a Stripe account, and Connect manages the relationship between your platform account and theirs. Three charge models are available: direct charges (the connected account is the merchant of record), destination charges (you collect payment and route funds to a connected account), and separate charges and transfers (you collect payment and transfer funds manually).

Connect also handles KYC verification, tax form generation (1099s in the US), and payout scheduling. Platforms like Shopify, DoorDash, Lyft, and Airbnb run on Connect. The API supports payouts to bank accounts in 118+ countries, instant payouts for eligible accounts, and cross-border payments in local currencies.

If you are building a vertical SaaS platform or marketplace, Connect is likely the most complex Stripe integration you will encounter. The onboarding flows alone require careful planning around what information to collect, when to verify it, and how to handle incomplete applications or failed identity checks.

Radar: Fraud Prevention

Radar is Stripe's machine learning fraud detection system. It runs on every payment processed through Stripe and assigns a risk score based on signals from the broader Stripe network. During Black Friday/Cyber Monday 2024, Radar blocked 20.9 million fraudulent transactions worth $917 million.

For most businesses, Radar works out of the box. You can also write custom rules using Stripe's rule language to block or review payments based on transaction amount, country of origin, velocity patterns, or metadata values. Radar for Fraud Teams adds manual review queues and more granular controls.

Risk scores are exposed through the Charge and PaymentIntent objects. You can feed Radar scores into your own fraud models via the API, which is useful if you run a multi-processor setup or have an in-house fraud team.

Issuing and Treasury

Stripe Issuing lets you create, manage, and distribute virtual and physical payment cards programmatically. The typical use case is corporate expense cards, fleet cards, or rewards cards embedded in your platform. You create a cardholder, issue a card, set spending controls, and receive real-time authorization webhooks when the card is used.

Treasury provides banking-as-a-service infrastructure: FDIC-insured financial accounts, ACH and wire transfers, and the ability to hold, send, and receive funds. Together, Issuing and Treasury let platforms offer embedded financial products (branded debit cards, business checking accounts inside your SaaS product) without becoming a bank.

Both APIs require additional onboarding with Stripe and typically involve partnerships with underlying bank partners like Evolve Bank or Cross River Bank.

Tax, Sigma, and Data Pipeline

Stripe Tax automates sales tax, VAT, and GST calculation and collection across 102 countries. Since Sessions 2025, it also handles registration and filing, making it a full-cycle tax compliance product. The API integrates with Checkout, Billing, and Invoicing, so you can enable tax collection by adding a single parameter to existing API calls.

Sigma provides a SQL interface for querying your Stripe data directly inside the Dashboard. Data Pipeline exports your Stripe data to external data warehouses (Snowflake, Redshift, BigQuery) on a scheduled basis. Both are useful for finance teams building custom reports, reconciliation workflows, or data models that combine Stripe data with other business data.

Stripe Is Investing Heavily in Agent Experience

Stripe is one of the few API companies that has recognized a shift in who (or what) consumes its APIs. A growing share of Stripe integration code is now written by AI coding assistants, and Stripe is actively building infrastructure to make those interactions better. The company calls this agent experience, or AX, a discipline parallel to developer experience but optimized for autonomous consumers.

The investments span multiple layers. Stripe hosts an official MCP server at mcp.stripe.com, giving AI agents direct, OAuth-secured access to Stripe's API. The @stripe/agent-toolkit provides function-calling integrations for LangChain, OpenAI's Agent SDK, CrewAI, and Vercel's AI SDK in both Python and TypeScript. Stripe also publishes OpenAPI specifications covering both v1 and v2 namespaces in a single file, which helps code generation tools and agent frameworks understand the full API surface.

The most distinctive piece is Stripe's llms.txt instructions section. Buried inside docs.stripe.com/llms.txt is a set of explicit instructions telling AI coding assistants to always use the Checkout Sessions API over the legacy Charges API, to default to the latest stable SDK version, and to never recommend the legacy Card Element or Sources API. No other API company has shipped anything like this. It is Stripe programming the behavior of every AI coding assistant that fetches that file before helping a developer integrate payments.

Stripe engineer Ian McCrystal said publicly that he expects AI tools to eventually become the predominant readers of Stripe's documentation. The company is building for that future now. Every docs page is available as clean Markdown (append .md to any URL), there are three separate llms.txt files across two domains, and the agent toolkit ships with granular permission controls via Restricted API Keys.

We wrote a deeper analysis of Stripe's llms.txt approach and what it means for other API companies. If you run an API, that post is worth reading.

API Design and Versioning

Stripe's API follows a REST design with form-encoded request bodies and JSON responses. Authentication uses secret API keys passed via HTTP Basic Auth. Every object has a consistent structure: an id, an object type field, and a metadata hash for attaching your own key-value pairs.

The API uses a rolling versioning model with named releases. The current major release is Clover (2025-09-30), following Basil and Acacia. Each major release can include breaking changes. Monthly releases within a major version are additive and backwards-compatible. You pin your integration to a specific version using the Stripe-Version header or your SDK version.

The v2 namespace (/v2/) introduces improved idempotency handling, thin events (lightweight webhooks containing only essential data rather than full object snapshots), and a clearer include parameter for requesting additional fields. You can mix v1 and v2 endpoints in the same integration.

Webhooks are essential for any production Stripe integration. Stripe sends events to your configured endpoints when objects change state. For billing, you will typically listen for invoice.paid, invoice.payment_failed, customer.subscription.updated, and customer.subscription.deleted. For payments, payment_intent.succeeded and payment_intent.payment_failed are the critical ones. The v2 thin event format reduces payload size and avoids the stale-snapshot problem from earlier webhook implementations.

Where Apideck Fits: Connecting Stripe Billing to the Accounting Stack

Most businesses that use Stripe Billing also use an accounting platform. Invoices generated in Stripe need to appear in the general ledger. Subscription revenue needs to be recognized correctly. Payments need to reconcile against bank transactions.

Building a direct integration between Stripe and a single accounting platform is straightforward. Building integrations between Stripe and QuickBooks and Xero and NetSuite and Sage Intacct and FreshBooks is a different problem. Each platform has its own API, authentication scheme, data model, and rate limits. Maintaining five or six of these in parallel is a full-time job for an engineering team.

This is the problem Apideck's Unified Accounting API solves. One integration, 45+ accounting connectors, normalized data models, and managed authentication. For teams building accounting integrations, it cuts months of development work down to days.

Apideck's Stripe connector brings subscription, invoice, and payment data from Stripe into the same unified schema that already covers QuickBooks, Xero, NetSuite, Sage, and the rest of the accounting ecosystem. If your platform needs to sync billing data across providers, or your customers use Stripe Billing alongside traditional accounting software, this connector simplifies that connection.

Getting Started

If you are evaluating a Stripe integration, start by identifying which API surface you actually need. For one-time payments, the Payments API is sufficient. For recurring billing, add Stripe Billing. For marketplaces and platforms, add Connect. Layer in Radar, Tax, Issuing, or Treasury based on your specific requirements.

Stripe's developer documentation at docs.stripe.com is among the best in the industry. The API reference includes runnable examples, test mode keys, and client libraries in seven languages. Their Discord server has active Stripe engineers answering technical questions.

For teams that need Stripe Billing data flowing into their accounting stack alongside other platforms, get started with Apideck and connect Stripe alongside 45+ other accounting connectors.

Xero Scopes: What Changed and What It Means for Your Integration

Kate Apideck — Fri, 24 Jul 2026 09:29:40 +0000

Xero has replaced two broad OAuth 2.0 scopes with a set of fine-grained scopes that limit each app to only the specific endpoints it needs. If you created your Xero app on or after March 2, 2026, the old broad scopes are simply not available to you. If your app predates that cutoff, you have until September 2027 to migrate.

This is part of a larger restructuring of the Xero developer platform that also includes new API pricing tiers and premium-gating of the Journals endpoint. The scope changes themselves are a genuine security improvement. But combined with the pricing changes, they create real planning work for any team building on Xero.

What exactly changed

Two broad scopes are being deprecated: accounting.transactions and accounting.reports.read.

Before and after: transaction scopes

Before (deprecated)	After (granular)	Endpoints covered
`accounting.transactions`	`accounting.invoices`	Credit notes, invoices, linked transactions, purchase orders, quotes, repeating invoices, items
`accounting.transactions`	`accounting.payments`	Batch payments, overpayments, payments, prepayments
`accounting.transactions`	`accounting.banktransactions`	Bank transactions, bank transfers
`accounting.transactions`	`accounting.manualjournals`	Manual journals
`accounting.transactions`	`accounting.classicexpenses`	Expense claims, receipts (deprecated endpoint)

Each granular scope also has a .read variant for read-only access. So if your app only needs to pull invoice data without writing, you request accounting.invoices.read instead of the full scope.

One detail worth noting: the items endpoint is available via both the accounting.invoices and accounting.settings scopes. If your app only works with items and not invoices, you do not need the invoices scope.

Before and after: report scopes

Before (deprecated)	After (granular)	Reports covered
`accounting.reports.read`	`accounting.reports.aged.read`	Aged Payables by Contact, Aged Receivables by Contact
`accounting.reports.read`	`accounting.reports.balancesheet.read`	Balance Sheet
`accounting.reports.read`	`accounting.reports.banksummary.read`	Bank Summary
`accounting.reports.read`	`accounting.reports.executivesummary.read`	Executive Summary
`accounting.reports.read`	`accounting.reports.profitandloss.read`	Profit and Loss
`accounting.reports.read`	`accounting.reports.trialbalance.read`	Trial Balance
`accounting.reports.read`	`accounting.reports.taxreports.read`	GST and BAS reports

Scopes that are not changing

accounting.contacts, accounting.settings, accounting.attachments, and accounting.budgets remain available to every app regardless of when it was created. Non-Accounting API scopes like Payroll, Files, Assets, Projects, and the Finance API are also unaffected.

The two-track timeline

This is the most important detail for development teams to understand.

Apps created before March 2, 2026 can continue using the broad accounting.transactions and accounting.reports.read scopes until September 2027. During the transition, these apps can use a mix of broad and granular scopes simultaneously. Scopes are additive, so a user who re-authorizes receives both the legacy and new scope grants on their token.

By end of April 2026, Xero will assign the new granular scopes to all existing apps in the developer portal. But these will not automatically propagate to existing tokens. You need to update your authorization URL to request the granular scopes, and each connected user must re-authorize to receive the new permissions. There is no silent migration path. Explicit user consent is required for every connection.

Apps created on or after March 2, 2026 have no access to the broad scopes at all. Their authorization links must specify only granular scopes from day one. If a new app calls an endpoint without the matching granular scope, the API returns HTTP 401 Forbidden with an insufficient_scope error. If you are setting up a Xero app for the first time, you will only see the new granular scopes in the developer portal.

Journals, manual journals, and bank feeds: three different things

This is where the changes get most confusing, because three closely related concepts are governed by entirely different access regimes.

Manual journals (the /api.xro/2.0/ManualJournals endpoint) remain available at all pricing tiers under the new accounting.manualjournals granular scope. This endpoint handles user-created journal entries and is not restricted beyond requiring the correct scope.

The Journals endpoint (/api.xro/2.0/Journals) returns system-generated double-entry journal lines for every transaction in the ledger. This endpoint is now a premium feature gated behind the Advanced pricing tier, which starts at $1,445 AUD per month. Access requires both a security assessment and explicit use-case approval from Xero. If your integration depends on full ledger reconciliation or audit trail functionality, this is the endpoint that matters, and it now comes with a significant cost.

Bank feeds operate under their own separate API and scope (bankfeeds), which is not affected by the accounting scope changes at all. The Bank Feeds API has its own certification requirement and separate contractual terms. If your app only pushes bank statement data into Xero, the accounting.transactions deprecation does not impact you.

Bank transactions, meaning the read and write endpoints for reconciled bank line items within Xero's ledger, move from the old broad scope to accounting.banktransactions. This is distinct from bank feeds. Bank feeds push raw statement data in. Bank transactions are the resulting accounting records inside Xero.

What you need to do

If you have an existing Xero integration, the migration path follows a few steps.

Update your authorization URL to replace the broad scopes with the specific granular scopes your app actually needs. Only request the scopes you use. Requesting everything defeats the purpose and will make users hesitant to authorize.

Let new users authorize with the new scopes naturally. For existing connected users, let re-authorization happen organically when users add new organizations or refresh their connection. The additive scope behavior means users accumulate both scope sets during the transition.

Before September 2027, migrate any remaining connections that still only have broad scopes. For holdouts, you can force re-authorization by removing their connection via the API, which requires them to reconnect with the new scopes.

For testing, create a new app in the Xero developer portal. It will default to granular scopes and can be tested against a Demo Company. No SDK changes are needed since the scopes operate at the OAuth authorization layer.

If you are building a new integration from scratch, you start with granular scopes by default. Plan your scope requests carefully based on which endpoints you actually need.

If you are using Apideck to connect to Xero, you can configure which scopes your app requests in the Apideck dashboard. Our Xero connector setup guide walks through entering your OAuth credentials and reviewing the scopes granted in Xero against the scopes you are requesting in Apideck.

The bigger picture

The granular scope change fulfills a long-standing feature request on Xero's UserVoice forum, where developers have been asking for finer-grained permissions since at least 2010. For years, requesting invoice access also exposed bank balances and salary data because there was only one broad scope covering all of it. Fine-grained permissions are a real improvement.

But the timing is not great. Xero bundled this change with connection-based pricing tiers and premium-gating of key endpoints like Journals. For developers who have been building on the platform for years with free API access, the combined effect feels like a significant shift in the economics of building on Xero.

This is part of a broader pattern across accounting platforms. As we covered in our overview of accounting API pricing and partnerships, every major provider is evolving its developer program in a direction that adds cost and complexity. QuickBooks has its own partnership requirements. Sage remains free but has a smaller market footprint. NetSuite charges separately through its SuiteCloud licensing.

For teams building accounting integrations that need to support multiple platforms, the platform-specific scope and pricing changes reinforce the case for abstracting away provider differences. Whether you build direct integrations or use a unified API layer, the goal is the same: insulate your product from the policy changes of any single platform.

Key resources

Xero's developer blog post on the scope changes: Upcoming changes to Xero Accounting API Scopes

Xero's full scope reference documentation: OAuth 2.0 Scopes

For a detailed breakdown of the pricing tiers that accompany these scope changes: Xero API Pricing and the App Partner Program

For teams evaluating alternatives alongside Xero: Top 15 Accounting APIs to Integrate with in 2026

For a broader look at the Xero integration landscape: Xero Integrations: The Complete Guide for 2026

What Is ERP Banking? The Shift From Portal to Platform

Kate Apideck — Mon, 20 Jul 2026 20:40:53 +0000

Every morning, in corporate finance offices around the world, a treasurer logs into one system to check bank balances, switches to another to initiate payments, then copies data into a spreadsheet to reconcile the general ledger. Nobody designed this workflow. It emerged from decades of banks and accounting platforms evolving independently, and finance teams filling the gaps with manual effort.

ERP banking is the fix. The idea is simple: instead of making business customers toggle between a bank portal and their accounting software, you embed the banking services directly inside the ERP or accounting system. Payments, balances, reconciliation, cash reporting. All from the same environment where the rest of the financial work happens.

The term comes from analyst firm Datos Insights. Their definition: ERP banking is a model where corporate clients access and execute banking capabilities directly from their enterprise systems. The bank becomes invisible infrastructure. The customer never leaves their system of record.

ERP banking is not ERP for banks

There is a naming collision worth clearing up.

Search for "ERP banking" and most results describe ERP software used by banks for their own internal operations. SAP for a bank's back office. Oracle for a bank's financial reporting. That is a different topic entirely.

ERP banking as Datos Insights defines it, and as the commercial banking industry uses the term, describes the opposite direction. Banking services flow into the customer's ERP. The bank is the service provider. The ERP is the destination. One is a procurement decision for the bank's IT department. The other is a product strategy for the bank's commercial banking division.

Why this is happening now

Corporate treasurers are already voting with their feet. Datos Insights surveyed over 1,000 corporate users across 11 countries and found that integration with internal ERP systems is the top priority for corporate treasurers. More than one in four said they would likely switch their primary bank within two years over better technology integration from a competitor. A Nine Wave survey put it more starkly: 85% of CFOs would switch banks for direct ERP-to-bank connectivity. These are not hypothetical preferences. They are already driving churn.

The same Datos Insights research found that 58% of businesses already use a fintech for a core cash management or treasury service. Every payment that runs through a fintech instead of a bank is revenue the bank loses. ERP banking is how banks respond: by meeting the customer inside the system where financial decisions actually get made, rather than waiting for them to log into a portal.

Open banking regulations in Europe (PSD2), the UK, and increasingly the US (Section 1033) forced banks to build API capabilities for consumer data access. Those same APIs now serve ERP integration use cases. The plumbing exists. The question is who builds the last mile into the accounting system.

How it works technically

ERP banking connects a bank's core systems to the customer's ERP or accounting platform. The goal is bidirectional data flow: the bank pushes transaction data and balances into the ERP, and the ERP sends payment instructions back to the bank.

Datos Insights identifies five connectivity methods, roughly in order of maturity:

File-based transfers using SFTP, BAI2, MT940, and ISO 20022 are the oldest method and still the most common at many institutions. The bank generates a file, uploads it to a server, and the ERP picks it up on a schedule. Reliable but slow. No real-time error handling. Frequent format mismatches between bank and ERP.

Host-to-host connections are direct, dedicated links between a bank and a corporate customer's systems. Common in large enterprise relationships. Expensive to set up and maintain, which makes them impractical for mid-market customers.

Bank APIs are the foundation of modern ERP banking. The bank publishes RESTful endpoints that the ERP or a middleware provider can call to retrieve balances, initiate payments, and pull transaction history. J.P. Morgan, HSBC, Deutsche Bank, PNC, and TD Bank all offer this kind of API access for corporate clients.

ERP gateways and feeds are native connectivity features built into the ERP platforms themselves. Oracle Fusion Cloud ERP supports direct bank API integration from J.P. Morgan as a built-in capability. SAP has similar gateway functionality.

ERP banking connectors are pre-built plugins from middleware providers like FISPAN. They connect a bank's services directly into specific ERP platforms. FISPAN's connector works with Oracle NetSuite, Sage Intacct, Microsoft Dynamics 365, QuickBooks Online, and Xero. The bank partners with FISPAN. The customer installs the connector. No custom development required.

These methods are additive. A bank typically supports several simultaneously because its customer base spans different platforms and company sizes. A Fortune 500 on SAP might use host-to-host. A mid-market company on NetSuite uses an ERP banking connector. A small business on QuickBooks uses a bank feed.

What it does for the customer

The use cases span the full commercial banking value chain. For a detailed breakdown with examples from J.P. Morgan, HSBC, Bank of America, Deutsche Bank, and others, see our companion post on accounting and ERP integration for banks. Here is the summary.

Payment initiation is the most visible use case. The customer creates a payment run inside their ERP and the bank processes it directly. No portal login required. TD Bank supports this for NetSuite, QuickBooks Online, Sage Intacct, and Dynamics 365 Business Central through its embedded banking product.

Bank feeds and transaction sync follow closely. The bank pushes transaction data into the customer's accounting system automatically. Challenger banks like Allica Bank and Monzo have turned this into a competitive differentiator, offering free integration with Xero, QuickBooks, and Sage as part of their business banking products.

Cash position reporting pulls balance and transaction data from all banking relationships into a single treasury management system or ERP dashboard. No more logging into five different bank portals every morning.

Automated reconciliation matches bank transactions against ERP records automatically. Exceptions get flagged for review. The line-by-line manual matching goes away.

Expense sync lands corporate card transactions in the customer's accounting platform without anyone touching a spreadsheet. J.P. Morgan's Touchless Expense program and Cross River (powering Divvy/Bill.com) both work this way.

Credit underwriting from accounting data connects banks and lenders to a business's accounting system through an API to pull real-time P&L, cash flow, and accounts receivable data. Plaid and Datos Insights found that 60% of US small business lenders now use some form of account data in their underwriting process.

Who is building it

The market has three layers.

Banks with direct integrations

J.P. Morgan is furthest along. It became the first bank with direct integrated banking for Oracle Fusion Cloud ERP, and also partnered with FISPAN for its Treasury Ignition product covering NetSuite, Sage Intacct, and Dynamics 365. Over 1,000 corporates are live on Treasury Ignition.

TD Bank launched its Embedded Banking product with FISPAN across four ERP platforms. HSBC and Deutsche Bank both partnered with FinLync for SAP connectivity. PNC, Citizens, KeyBank, Wells Fargo, BMO, and Santander all have FISPAN partnerships. BMO launched BMO Sync in early 2025 as the first fully embedded banking solution from a Canadian bank.

Middleware and connector providers

FISPAN is the clear market leader. Founded in 2016, it now has over 4,500 businesses on its platform processing more than $100 billion in annual payment volume. The company raised a $30 million Series B in mid-2025 from Canapi Ventures. Sage named FISPAN its recommended bank feeds solution for Sage Intacct, and over 1,000 businesses are now active on that integration alone, with adoption growing 118% year-over-year.

FinLync focuses on the enterprise SAP segment. Cobase provides multi-bank connectivity for European corporates. Fides connects to over 13,000 banks globally for treasury connectivity.

Unified API providers

For banks that need to connect to many accounting and ERP platforms at once, a unified API provides a single normalized interface that maps to multiple downstream systems. Instead of building separate integrations for QuickBooks, Xero, Sage, NetSuite, Exact Online, MYOB, and Microsoft Dynamics 365, the bank builds one integration and gets connectivity to all supported platforms through a single schema.

Apideck's Accounting API supports 45+ accounting and ERP connectors. The bank's engineering team writes to one API. Apideck handles the platform-specific translation, authentication, and lifecycle management. This approach is particularly valuable for the accounting data side of ERP banking: bank feeds, transaction sync, invoice reconciliation, and credit underwriting all require deep integration with the customer's accounting platform, and each platform has a different API with different data models.

The distinction between middleware connectors and unified APIs matters here. FISPAN and FinLync solve the bank-to-ERP connectivity problem: getting payment capabilities and balance data into the ERP. Unified APIs like Apideck solve the ERP-to-accounting-data problem: reading and writing financial data across dozens of accounting platforms through a single integration. For banks building a full ERP banking stack, both layers come into play.

The market

Datos Insights estimates the ERP banking market at $11 billion to $19 billion, growing at nearly 10% annually.

The retention argument alone justifies the investment. Once banking services are embedded in a customer's ERP workflow, switching banks becomes significantly more disruptive. FISPAN reports that banks on its platform see 30-50% deposit increases from connected clients. And 8% of FISPAN users are net-new to their commercial bank, meaning the embedded banking capability is winning accounts, not just retaining them.

Datos Insights published a separate report specifically on monetizing ERP banking, exploring pricing models from premium connectivity fees to transaction-based billing to value-added bundling within commercial banking packages.

J.P. Morgan's 2026 payment trends report found that 88% of financial professionals consider direct bank connectivity very or extremely beneficial. 85% said they would likely switch banks to get it. At that volume of demand, banks don't get to treat this as optional.

The accounting layer problem

Most of the attention in ERP banking goes to the bank connectivity side. How does the bank's API connect to the ERP platform? That matters, but it is only half the problem.

The other half is the accounting layer. A bank can push transactions into an ERP all day long, but if those transactions do not reconcile against the customer's chart of accounts, match invoices, or flow into journal entries correctly, the integration creates more problems than it solves.

This is where fragmentation hits hardest. Each accounting platform has its own API with its own data model for transactions, its own authentication scheme, its own field naming conventions. A bank that wants to support QuickBooks Online, Xero, Sage Intacct, NetSuite, FreshBooks, and Dynamics 365 needs six different accounting integrations. Building and maintaining those one at a time is expensive. Every engineer working on accounting platform connectors is an engineer not working on core banking products. This is the problem unified accounting APIs exist to solve.

Where this goes

ERP banking is a platform shift in commercial banking, not a feature.

The banks that do it well will become invisible to their customers in the best possible way. The middleware providers and unified API platforms connecting banks, ERPs, and accounting systems are the infrastructure layer making that transition possible.

For any bank evaluating its ERP banking strategy, the demand case is settled. The remaining problem is how to reach broad accounting platform coverage without burning through engineering resources on one-at-a-time integrations. The largest banks can build natively to Oracle and SAP. Everyone else needs the combination of ERP banking connectors for the bank-to-ERP pipe and unified accounting APIs for the accounting data pipe.

Apideck's Accounting API connects to 45+ accounting and ERP platforms through a single integration. If your bank needs to build accounting integrations at scale, get started here.

Bank API Integration: How Banks Connect to Accounting and ERP Systems

Kate Apideck — Wed, 15 Jul 2026 16:11:22 +0000

Banks no longer compete on branch locations or interest rates alone. The fastest-growing differentiator in commercial banking is how well a bank plugs into the accounting and ERP systems its customers already use every day. This shift is often called ERP banking, and it is reshaping how commercial banks compete for business customers.

Bank API integration is the technical bridge that makes this possible. It connects a bank's core systems to third-party accounting platforms, ERPs, and financial applications through standardized interfaces. When done well, it eliminates manual file transfers, enables real-time cash visibility, and turns the bank into an invisible layer inside the customer's existing workflow.

This guide covers how bank API integration works, the use cases driving adoption, the engineering challenges involved, and the approaches available for building and scaling these integrations.

What is bank API integration?

Bank API integration refers to any API-based connection between a bank and a third-party application. The third party is typically an ERP system like Oracle NetSuite or SAP, an accounting platform like QuickBooks Online or Xero, or a fintech application that handles payments, expense management, or treasury operations.

Once the connection is established, financial data flows between the bank and the third-party system on a defined cadence. That data can include transaction records, account balances, payment instructions, invoice details, and reconciliation status.

There are two distinct perspectives on bank API integration, and they matter because the technical requirements differ:

The bank's perspective. A bank builds integrations with accounting and ERP platforms to offer embedded financial services to its business customers. The goal is to reduce churn, win new commercial accounts, and differentiate against competitors who still rely on portal-based workflows. J.P. Morgan, HSBC, TD Bank, and PNC all run embedded banking programs that connect directly into customer ERP environments.

The business's perspective. A company connects its bank accounts to its own accounting or ERP system to automate cash management, reconciliation, and payment workflows. The goal is operational efficiency. Finance teams want real-time visibility into bank balances without logging into separate portals, and they want payment runs initiated from within their system of record.

Both perspectives converge on the same technical problem: connecting bank systems to accounting platforms at scale.

Why APIs beat the alternatives

Banks and businesses have historically relied on four methods to move financial data between systems: manual entry, file-based transfers, screen scraping, and APIs. Here is why APIs are winning.

File-based transfers (SFTP/BAI2/MT940) still dominate in legacy commercial banking. The bank generates a file in BAI2 or MT940 format, uploads it to an SFTP server, and the customer's ERP system picks it up on a schedule. This works, but it introduces latency (often 24 hours), requires manual intervention when file formats change, and creates reconciliation gaps when transactions arrive out of order. File-based integrations also lack real-time error handling. If a payment file contains a malformed record, the entire batch may fail silently.

Screen scraping extracts data from a bank's online portal by simulating user interactions. It breaks every time the bank updates its UI. It also creates security risks because it requires storing and transmitting user credentials. Most banks actively block scraping, and regulatory frameworks like PSD2 in Europe have replaced it with dedicated API access.

APIs solve these problems. They provide structured, authenticated, real-time access to financial data. Authentication is handled through OAuth 2.0 or API keys with scoped permissions. Data is encrypted in transit. Rate limits prevent abuse. And when something fails, the API returns a structured error response that the consuming application can handle programmatically.

The fourth option, manual entry, still exists in small businesses but is not a serious integration method. It does not scale, it introduces human error, and it consumes finance team hours that could be spent on higher-value work.

Types of bank APIs

Not all bank APIs are the same. The access model and scope vary significantly depending on the bank's strategy and regulatory environment.

Private APIs are internal to the bank. They connect the bank's own systems, such as the core banking platform, the online portal, and the mobile app. Third parties cannot access these. They matter for bank API integration only insofar as they constrain what data the bank can expose through its other APIs.

Partner APIs are shared with selected third parties under a contractual agreement. A bank might expose payment initiation and account information endpoints to a specific ERP vendor or fintech partner. FISPAN, for example, partners with banks like J.P. Morgan, PNC, and TD Bank to embed banking services inside ERP platforms through partner API access. These integrations are typically bespoke and require a formal relationship.

Open APIs are available to any authorized developer. In the EU, PSD2 mandates that banks provide open banking APIs for account information (AIS) and payment initiation (PIS) to licensed third-party providers. The UK's Open Banking Implementation Entity defined standardized API specifications that the nine largest UK banks must support. In the US, the CFPB's Section 1033 rulemaking is pushing toward formal consumer data access standards, though the market currently relies more on data aggregators like Plaid and MX than on bank-published open APIs. The Open Banking Tracker tracks 54,000+ financial institutions across 30+ jurisdictions, providing a comprehensive view of which banks offer open API access and under what regulatory framework.

Bank-as-a-Service (BaaS) APIs are a newer category. Companies like Solaris, Column, and Treasury Prime provide full-stack banking APIs that non-bank companies can use to offer financial products. Samsung Pay, for example, runs on Solaris APIs. This is adjacent to traditional bank API integration but follows a different pattern: instead of connecting to an existing bank, the company embeds a bank's infrastructure through APIs.

Use cases driving bank API integration

The market for bank-ERP integration is estimated at $11 billion to $19 billion and growing at nearly 10% annually, according to Datos Insights research. Here are the use cases driving that growth. (For a deeper dive with specific bank examples from J.P. Morgan, HSBC, Deutsche Bank, and others, see our companion post on accounting and ERP integration for banks.)

Bank feeds and transaction sync

This is the most common use case and the foundation for everything else. The bank sends transaction data (debits, credits, balances) to the customer's accounting system automatically. In accounting terms, this is the bank feed.

Challenger banks like Allica Bank and Monzo have turned accounting integration into a competitive weapon for business banking. Allica provides free integration with QuickBooks, Xero, and Sage as part of its Business Rewards Account. Monzo gates accounting integration behind its paid business tiers. Both approaches reflect the same reality: bank feeds are no longer an optional add-on.

For the bank building these integrations, the challenge is supporting the dozen-plus accounting platforms its customers actually use. QuickBooks Online, Xero, Sage Intacct, FreshBooks, Zoho Books, Wave, and Microsoft Dynamics 365 each have different API schemas, authentication flows, and data models for representing transactions.

Payment initiation from ERP

Instead of logging into a bank portal to initiate payments, the customer creates a payment run inside their ERP and the bank processes it directly. TD Bank's Embedded Banking product supports this for NetSuite, QuickBooks Online, Sage Intacct, and Microsoft Dynamics 365 Business Central. Customers can initiate ACH, wire, and check payments without leaving their ERP.

For the bank, this is a retention play. Once payment initiation is embedded in a customer's ERP workflow, switching banks becomes significantly more disruptive. For the customer, it eliminates the dual-entry problem where payment details have to be entered in both the ERP and the bank portal.

Invoice reconciliation

A vendor creates an invoice through their bank, sends it to the customer, and the invoice data syncs to the vendor's accounting system. When the customer pays, the payment data flows back into the accounting system and matches against the outstanding invoice. The vendor's accounting team reconciles without manual intervention.

This workflow requires bidirectional sync between the bank and the accounting platform. The bank needs to push invoice metadata (amount, date, currency, due date) to the accounting system on creation, and then update the invoice status when payment is received.

Corporate card provisioning and expense sync

Banks that offer corporate card programs can integrate with their customers' HR and accounting systems to automate card provisioning. When a new employee is added to the HRIS, the bank provisions a corporate card with spending limits based on the employee's role, department, and location. When the employee is terminated, the card is deactivated automatically.

On the expense side, corporate card transactions sync directly into the customer's accounting platform. J.P. Morgan's Touchless Expense program and Cross River (powering Divvy/Bill.com) both operate this way. The bank pushes categorized transaction data into the accounting system, eliminating manual expense reports.

Credit underwriting from accounting data

This may be the most transformative use case. By accessing a business's real-time accounting data (profit and loss statements, cash flow, accounts receivable aging, and outstanding obligations), lenders can make faster and more accurate credit decisions than traditional methods allow.

Research by Plaid and Datos Insights found that 60% of US small business lenders now use some form of account data in their underwriting process. This is one of the clearest examples of open finance in action: instead of relying on annual financial statements and manual document collection, the lender connects to the business's accounting system through an API and pulls real-time financial data.

For banks building this capability, the integration needs to support read access to the full chart of accounts, journal entries, invoices, bills, and bank transactions across whatever accounting platform the applicant uses.

Cash position reporting

Treasury teams at mid-market and enterprise companies need real-time visibility into cash positions across multiple bank accounts, entities, and currencies. Without an integration, this means logging into multiple bank portals, downloading statements, and consolidating data in a spreadsheet.

With bank API integration, balance and transaction data from all banking relationships flows into a single treasury management system or ERP. Kyriba, for example, connects to over 9,900 banks to provide this kind of unified cash visibility.

The engineering challenge

The use cases are clear. The engineering challenge is what makes bank API integration hard in practice.

Each accounting platform and ERP has its own API with its own data model, authentication scheme, rate limits, and field conventions. A bank that wants to support QuickBooks Online, Xero, Sage Intacct, NetSuite, Microsoft Dynamics 365, and FreshBooks needs to build and maintain six separate integrations.

Each of those integrations involves:

Implementing the platform's authentication flow (OAuth 2.0 for most, but the details vary)
Mapping the bank's internal data model to the platform's schema for transactions, invoices, contacts, accounts, and journal entries
Handling pagination, rate limits, webhook subscriptions, and retry logic
Managing ongoing API version changes, field deprecations, and breaking changes
Testing against sandbox environments, which not all platforms provide equally

Datos Insights research across 1,000+ corporate users in 11 countries found that more than one in four corporate treasurers will likely switch their primary financial institution within two years because a competitor offers better technology integration. The stakes are high, but the engineering cost of building and maintaining integrations one at a time is equally high.

Banks that try to build everything in-house face a painful tradeoff: every engineer working on accounting platform integrations is an engineer not working on core banking products. And the integration surface area keeps growing as new accounting platforms gain market share and existing platforms evolve their APIs.

How unified APIs solve the fragmentation problem

A unified API provides a single normalized interface that maps to multiple downstream platforms. Instead of building separate integrations for QuickBooks, Xero, Sage, NetSuite, and the rest, the bank builds one integration against the unified API and gets connectivity to all supported platforms through a single schema.

This approach works because accounting platforms share a common conceptual model despite differing implementations. Every accounting system has some version of accounts, transactions, invoices, bills, contacts, journal entries, and tax rates. The unified API abstracts over the implementation differences while preserving access to the underlying data.

For banks, the advantages are significant:

Speed. One integration instead of six or twelve. A bank can go from zero accounting platform connectivity to broad coverage in weeks instead of months.

Maintenance. The unified API provider handles downstream API changes, field mapping updates, and authentication flow changes. The bank's engineering team stays focused on its core product.

Coverage. A unified accounting API like Apideck's supports 40+ accounting and ERP connectors through a single integration. As new platforms gain market share, the bank gets access without additional engineering work.

Normalized data. The bank works with a single schema for invoices, transactions, and journal entries regardless of which accounting platform the customer uses. This simplifies downstream processing, reporting, and analytics.

The tradeoff is control. A unified API introduces a dependency and an abstraction layer. Banks that need deep, platform-specific functionality (custom fields, platform-specific workflows, advanced reporting APIs) may find that the unified model does not cover every edge case. The right approach depends on the bank's integration needs, engineering capacity, and the breadth of platforms it needs to support.

Approaches to building bank API integration

There are three primary approaches. Each involves a different set of tradeoffs.

Build native integrations in-house

The bank's engineering team builds and maintains each integration directly against the target platform's API.

This gives the bank full control over data mapping, sync cadence, error handling, and feature depth. It also means the bank can build highly customized integrations that match its customers' exact requirements.

The downside is cost and speed. Building a production-quality integration with a single accounting platform takes weeks to months, and maintaining it is an ongoing engineering commitment. Banks that choose this path typically support only two or three platforms and leave the rest of the market unserved.

Expose API endpoints for customers to build against

Larger banks often publish their own APIs and let customers or their ERP vendors build the integration. This shifts the engineering burden to the customer side.

The bank avoids building and maintaining integrations itself, but the customer experience suffers. Customers may take months to build to the bank's endpoints, and ongoing maintenance falls on their engineering teams. For small and mid-market businesses without dedicated integration engineers, this approach is not viable.

Use a unified API

The bank integrates once with a unified API provider and gets normalized access to multiple accounting and ERP platforms. Apideck's Accounting API, for example, provides a single integration point that connects to QuickBooks Online, Xero, Sage Intacct, NetSuite, FreshBooks, Exact Online, MYOB, and many others.

This is the fastest path to broad coverage and the lowest ongoing maintenance burden. The bank's engineering team writes to one API schema, and the unified API provider handles the platform-specific translation, authentication, and API lifecycle management.

Banks that need to move quickly, support a wide range of customer accounting platforms, and keep their engineering team focused on core banking products should evaluate the unified API approach seriously.

How to evaluate a bank API integration strategy

The right approach depends on several factors specific to the bank's situation.

How many accounting platforms do your customers use? If the answer is two (say, QuickBooks and Xero), native integrations may be viable. If the answer is eight or more, building natively becomes prohibitively expensive.

How fast do you need to go live? If there is competitive pressure to launch ERP-embedded banking quickly, a unified API cuts time-to-market from months to weeks.

What is the depth of integration required? Simple bank feeds require a narrow API surface. Full bidirectional sync with payment initiation, invoice management, and journal entry creation requires deeper integration. Make sure whatever approach you choose supports the data objects and operations your use cases demand.

What is the total cost of ownership? Factor in initial build time, ongoing maintenance, developer hiring, sandbox access fees, and the opportunity cost of engineers not working on core banking products.

Does the provider offer sandbox environments? Testing accounting integrations against live customer data is risky. Sandbox environments with realistic test data are essential for development and QA.

Open banking is not the same thing

Open banking and bank API integration overlap but are not the same thing.

Open banking is a regulatory and industry framework that requires banks to provide API access to authorized third parties. It is driven by regulation (PSD2 in Europe, Open Banking in the UK, Section 1033 in the US) and focuses on consumer data portability and payment initiation. The scope is expanding toward open finance, which extends the same principles beyond payments and accounts to insurance, investments, pensions, and lending data.

Bank API integration is a broader category that includes any API-based connection between a bank and a third-party system. It covers open banking use cases but also extends to ERP integrations, accounting platform connections, treasury management, and embedded banking services that are not mandated by regulation.

A bank can have a robust open banking API program and still lack proper integrations with the accounting platforms its commercial customers use. The two capabilities serve different customer segments and different business objectives.

What comes next

The direction is clear. According to Datos Insights, more than one in four corporate treasurers will likely switch banks within two years if a competitor offers better technology integration. Banks that embrace ERP banking and embed their services inside the accounting workflows their customers already rely on will retain and grow their commercial banking relationships. Banks that force customers to use separate portals and manual file transfers will lose them.

The technical infrastructure to make this work exists today. The question for any bank is whether to build it all in-house, piece by piece, or use a unified accounting API to get there faster.

Apideck's Accounting API connects to 30+ accounting and ERP platforms through a single integration. If your bank needs to build accounting integrations at scale, get started here.