DEV Community: 𝚂𝚊𝚞𝚛𝚊𝚋𝚑 𝚁𝚊𝚒

I've created a detailed guide for building on top of Accounting APIs, let me know your thoughts or anything that you want to build.

𝚂𝚊𝚞𝚛𝚊𝚋𝚑 𝚁𝚊𝚒 — Thu, 05 Mar 2026 05:42:44 +0000

𝚂𝚊𝚞𝚛𝚊𝚋𝚑 𝚁𝚊𝚒 for Apideck

Mar 5

Accounting Integration

#api #backend #startup #erp

Comments

14 min read

Accounting Integration

𝚂𝚊𝚞𝚛𝚊𝚋𝚑 𝚁𝚊𝚒 — Thu, 05 Mar 2026 05:42:01 +0000

Your finance team didn't sign up to be data-entry clerks. Neither did your customers.

Yet every day, thousands of businesses manually export transactions from QuickBooks, copy invoice data from Xero, or reconcile payments between three different spreadsheets. It's slow, error-prone, and a waste of skilled people's time.

Accounting integrations fix this. They connect your software directly to your customers' general ledger, automatically syncing invoices, expenses, payments, and journal entries. No CSV exports. No copy-paste errors. No "we'll reconcile it at month-end."

This guide covers what accounting integrations actually do, the most common use cases, and how companies like Ramp, Airbase, and BILL have leveraged them to gain a competitive advantage.

The open accounting movement is driving demand for standardized data access across accounting platforms, making integration capabilities a competitive requirement for B2B SaaS products.

What Is an Accounting Integration?

An accounting integration is a connection between your application and an accounting platform like QuickBooks, Xero, NetSuite, or Sage Intacct. It allows data to flow between systems, either one-way or bidirectionally, without manual intervention.

A quick definition, if you're new to this: A general ledger (GL) is the master record of all financial transactions in a business. Every transaction gets tagged with a GL code, which is essentially a label that categorizes where the money went: "Travel," "Software Subscriptions," "Office Supplies," and so on. When we talk about syncing to the GL, we mean getting your data into that master record with the right labels attached.

At a practical level, accounting integrations mean:

Invoices created in your billing system appear automatically in your customer's accounting software
Expenses logged in your app push directly to the general ledger with the correct GL codes
Payments recorded in one system update the other in real time
Bank transactions reconcile automatically instead of requiring manual matching

The alternative is what most businesses still do: export a CSV, open Excel, clean the data, reformat it for the accounting system, import it, and hope nothing gets lost in translation. Multiply that by hundreds of transactions per month, and you've created busywork that produces no value.

Why Accounting Integrations Matter for Your Product

If you're building software that touches money (invoicing, expense management, payroll, procurement, lending, payments), your customers will eventually ask: "Does this connect to our accounting system?"

The answer determines whether you're a tool they'll actually adopt or one they'll abandon after the free trial.

The business case is straightforward:

Faster sales cycles. Enterprise buyers have procurement checklists. "Integrates with NetSuite" is often a required line item. Without it, you don't make the shortlist.
Lower churn. Customers who integrate your product into their financial workflows don't leave easily. The switching cost is too high when your app is integrated into their month-end close process.
Higher contract values. Integration features justify premium pricing. Ramp charges more for deeper ERP connections. So does BILL. Customers pay for the time savings.
Reduced support burden. Every "how do I export this to QuickBooks?" ticket is a symptom of a missing integration. Build it once, eliminate the ticket category.
Market expansion. Companies across specific regions, industries, and sizes use certain accounting tools. SMBs gravitate toward QuickBooks and Xero. Mid-market and enterprise prefer NetSuite, Sage Intacct, and Microsoft Dynamics. Offering integrations with the tools your target markets rely on opens doors that would otherwise stay closed.

Two Types of Accounting Integrations

Before diving into use cases, it's worth distinguishing between two categories:

Customer-Facing (Product) Integrations

These connect your product to your customers' accounting systems. They're what this guide focuses on—the integrations that become product features, drive sales conversations, and require supporting hundreds of different customer configurations.

The rest of this guide addresses customer-facing integrations, which present unique challenges around multi-tenancy, authorization, and scale.

Internal Integrations

These connect your company's own systems. For example:

CRM → Accounting: When an opportunity closes in Salesforce, automatically create the customer in NetSuite for invoicing
Accounting → BI: Sync financial data from Xero to Tableau for executive dashboards
Accounting → Slack: Alert the finance channel when invoices are overdue

These are typically built with iPaaS tools (Workato, Tray) or custom scripts. They're one-off connections serving your internal workflows.

6 Common Use Cases for Accounting Integrations

1. Expense Management → General Ledger Sync

The problem: Employees submit expenses. Finance approves them. Then someone manually enters each line item into QuickBooks with the correct GL code, department, and tax treatment.

The integration: Approved expenses push automatically to the accounting system. GL codes mapped by expense category. The finance team reviews exceptions, not every transaction.

Who does this well: Brex, Expend, ExpenseOnDemand, Ramp, and Airbase all sync expenses directly to QuickBooks, Xero, NetSuite, and Sage Intacct. For corporate card products, this is now table stakes. Invoice2go by BILL used Apideck's Unified API to speed up accounting integrations across multiple platforms, enabling support for major systems without custom builds. This helped them scale expense and reporting features quickly across over 220,000 customers worldwide.

Below is what the QuickBooks Online integration looks like on Ramp after you set it up.

2. Invoicing and Billing → Accounts Receivable

The problem: Your product generates invoices. Your customer's accounting team needs those invoices in their accounts receivable ledger. Right now, they're downloading PDFs and manually creating entries.

The integration: Invoices created in your system automatically appear in the customer's accounting platform. Payment status syncs back. When the invoice is paid, both systems reflect it without anyone having to touch a keyboard.

Who does this well: Stripe's invoicing connects to QuickBooks and Xero. Chargebee syncs subscription invoices to major accounting platforms. Any serious billing tool offers this now. For example, Roopairs used Apideck's Unified API to launch a QuickBooks Online integration quickly, saving roughly 40 developer hours and supporting 30 active customers from day one. The team is now planning expansions to Sage Intacct and NetSuite due to the speed and simplicity of the implementation.

Stripe QuickBooks Online integration guide

3. Procurement and AP Automation → Purchase Order Matching

The problem: A company issues a purchase order. Goods arrive. An invoice comes in. Someone has to manually match the PO, receipt, and invoice (the "three-way match") before approving payment.

The integration: Your procurement system shares PO data with the accounting platform. When invoices arrive, matching happens automatically. Exceptions flag for review; clean matches process straight through.

Who does this well: Coupa, SAP Ariba, and newer players like Zip connect procurement workflows directly to ERPs for automated matching and approval routing. For example, Derive used Apideck's Unified API to reduce development time by about 70 percent. They went from sign-up to a live Xero integration in just three weeks and later launched a Workday connection in under 90 days, which helped accelerate sales cycles and expand into enterprise markets more quickly.

Coupa Invoice Matching Explained

4. Revenue Recognition → Compliance with Accounting Standards

The problem: SaaS companies with usage-based pricing or multi-element contracts can't just recognize revenue when cash hits the bank. Accounting standards like ASC 606 require recognizing revenue over the service period. In plain English: you have to follow specific rules about when you're allowed to say you've "earned" money. Calculating this manually across thousands of subscriptions is an audit nightmare.

The integration: Your billing system sends contract and usage data to the accounting platform. Revenue schedules are generated automatically based on the rules. Auditors get clean documentation without your team building spreadsheets.

Who does this well: Stripe Revenue Recognition, Chargebee's RevRec module, and dedicated tools like Leapfin pull transaction data and push compliant journal entries to NetSuite or Sage Intacct.

Chargebee RevRec Features

5. Embedded Fintech → Real-Time Cash Flow Visibility

The problem: Lending platforms, cash flow tools, and financial dashboards need to see a business's real financial position. Bank feeds show cash movement, but not the full picture: receivables, payables, revenue trends, and outstanding invoices.

The integration: Pull chart of accounts, invoices, bills, and journal entries from the customer's accounting system. Display real-time financial health. Underwrite loans based on actual accounting data, not uploaded bank statements from three months ago.

Who does this well: Plaid handles banking data; accounting integrations from providers like Codat and Apideck fill in the rest. Lenders like Clearco and Pipe use accounting data to underwrite in hours instead of weeks.

For a technical deep-dive on this pattern, see Using Accounting APIs for Smart Lending Decisions.

Plaid API Docs

6. AI and Machine Learning → Financial Intelligence

The problem: You want to offer AI-powered features: budget predictions, anomaly detection, and cash flow forecasting, but your models need comprehensive financial data from each customer.

The integration: Pull balance sheets, income statements, transaction histories, and accounts receivable aging from customers' accounting systems. Feed this data to your ML models for personalized insights. As new transactions flow in, models update automatically.

Who does this well: Runway, Jirav, and Mosaic pull accounting data to power FP&A automation. Fintech platforms use it to build credit models that outperform traditional underwriting.

Runway Fintech Platform

How Companies Build Accounting Integrations

This is where product decisions become engineering reality. You have three paths:

Option 1: Build Direct Integrations

Connect to each accounting platform's API individually. QuickBooks Online has a REST API. Xero uses OAuth 2.0. NetSuite offers both SOAP and REST. Sage has several APIs, depending on which Sage product you're targeting.

Pros: Full control over the integration. Access to every feature the platform offers.

Cons: Each integration is a significant investment. Industry estimates indicate that a single integration requires 150+ engineering hours to build and 300+ hours annually to maintain, with total costs ranging from $10,000 to $50,000 per integration per year, including engineering time, customer success support, and ongoing maintenance. Supporting 10 accounting systems means multiplying that investment tenfold. Teams routinely estimate six weeks and ship in three months, as auth flows alone can derail timelines.

The maintenance reality: Accounting APIs change. QuickBooks pushes updates. Xero deprecates endpoints. NetSuite releases new versions. When a sync breaks on the first of the month (the worst possible timing for any finance team), someone on your team is firefighting instead of building features. Direct integrations require ongoing "on-call" capacity that most teams underestimate.

Option 2: Use a Unified API

A unified API provider normalizes multiple accounting platforms into a single integration. Think of it as a universal translator: your system speaks one language, and the provider handles the dialects of QuickBooks, Xero, NetSuite, and the rest.

You build once; they maintain the connections.

Pros: Launch in weeks instead of months. One data model to learn. One auth flow to implement. Coverage across platforms without multiplying your engineering investment. Unified API approaches typically deliver 3-5x faster implementation with significantly lower total cost of ownership over multi-year periods.

Cons: You're dependent on the provider's coverage depth and data model. Some edge cases or advanced features may still require direct API work for specific platforms.

Providers in this space: Apideck, Merge, Codat, Railz, and Rutter all offer unified accounting APIs with varying coverage, pricing models, and approaches to data normalization. For a detailed comparison, see Top Merge API Alternatives for SaaS Teams in 2025.

Not sure whether to build or buy? Read Build vs Buy Accounting Integrations.

Option 3: Hybrid Approach

Use a unified API for 80% of your coverage (common platforms and standard use cases), then build direct integrations for strategic accounts that require deep customization. This typically means NetSuite or SAP for enterprise deals that require custom fields, advanced workflows, or specific ERP modules.

How to Prioritize Which Integrations to Build

As you can't build everything at once. Use this framework to prioritize and insert the Accounting integrations that are relevant:

Criteria	Weight	QuickBooks	NetSuite	Xero	Sage Intacct
% of pipeline requesting	25%	?	?	?	?
Expected close rate lift	20%	?	?	?	?
Retention impact	20%	?	?	?	?
New market access	15%	?	?	?	?
Engineering effort	10%	?	?	?	?
Maintenance burden	10%	?	?	?	?
Weighted Score	100%	?	?	?	?

Integration Prioritization Scorecard

How to use it:

Survey your sales team: which integrations come up most in deals?
Analyze lost deals: how many cited missing integrations?
Segment by customer size: SMB skews QuickBooks/Xero, enterprise skews NetSuite/Sage
Score each integration, calculate weighted totals, and stack-rank

This prevents the common mistake of building integrations based on engineering interest rather than business impact.

Common Pitfalls: What Goes Wrong with Accounting Integrations

Most integration guides tell you what to build. Few tell you what breaks. Here are the failure modes that create support tickets, churn, and 2 AM pages:

1. Auth Token Expiry and Refresh Failures

OAuth tokens expire. Refresh tokens have their own lifespans. QuickBooks tokens last 100 days; if a customer doesn't use the integration for three months, it silently breaks. Your sync stops, but no one notices until month-end close—when the finance team is already stressed.

The fix: Proactive token health monitoring. Alert customers before re-authentication is needed, not after data stops flowing.

2. Schema Drift and API Changes

Accounting platforms don't freeze their APIs. QuickBooks pushed breaking changes to their invoice endpoints in 2023. Xero periodically deprecates fields. NetSuite's SuiteTalk versions introduce incompatibilities.

The fix: Version your integrations. Monitor API changelogs. Build regression tests that catch schema changes before customers do.

3. Rate Limit Hell

QuickBooks allows 500 requests per minute. Sounds generous until you're syncing 10,000 invoices for a new customer. Hit the limit, and your sync backs up. Customers see stale data. Support tickets pile up.

The fix: Implement exponential backoff. Queue and batch requests. Design for burst limits from day one, not after you hit them in production.

4. Multi-Entity and Multi-Currency Complications

Enterprise customers don't have one QuickBooks company. They often manage twelve subsidiaries across three currencies. Your integration works perfectly for single-entity SMBs, then breaks spectacularly when an enterprise customer connects their consolidated NetSuite instance.

The fix: Design for multi-entity from the start. Ask during onboarding: "How many entities will you connect?" If the answer is more than one, adjust your data model accordingly.

5. GL Code Mapping Mismatches

Your expense categories don't match your customer's chart of accounts. "Travel" in your system needs to map to "6200 - Employee Travel & Entertainment" in theirs. Get it wrong, and transactions land in the wrong accounts or fail to sync entirely.

The fix: Build a mapping interface. Let customers configure how your categories translate to their GL codes. Don't assume your defaults work for everyone.

6. Partnership Agreement Delays

Many enterprise accounting vendors (especially Sage, Xero, Intuit, and SAP) require formal partnership agreements before you can access sandbox environments or API documentation. These agreements can take months, sometimes over a year, and cost tens of thousands annually.

The fix: Start partnership applications early, before you need the integration. If the timeline is critical, consider unified API providers who already have these partnerships in place.

What to Look for in an Accounting Integration Solution

Whether you're evaluating unified API providers or scoping direct builds, here's what actually matters:

Platform coverage. Does it support the accounting systems your customers use? QuickBooks and Xero dominate SMB. NetSuite, Sage Intacct, and Microsoft Dynamics serve the mid-market and enterprise. Know your customer base before choosing. Need a full breakdown? See Top 15 Accounting APIs to Integrate with in 2025.
Data model depth. Can you access invoices, payments, journal entries, tracking categories, tax rates, and custom fields? Or just the basics? Shallow integrations create support tickets later.
Write access. Reading data is the easy part. Pushing invoices, expenses, or journal entries back to the accounting system is harder but more valuable. Confirm bidirectional sync works if you need it.
Auth experience. Your customers connect to your accounting system via an OAuth flow. If that flow is clunky, confusing, or breaks frequently, your support team will hear about it.
Webhooks and real-time sync. Polling for changes is slow and burns API quota. Webhooks let you react to new invoices or payments the moment they happen.
Security and compliance. You're touching general ledger data. Customers will ask about SOC 2 compliance, data encryption, and where their credentials are stored. Have answers ready, or choose a provider who does.
Integration observability. When syncs fail, can you see why? Look for logging, error categorization, and alerting that help your support team diagnose issues without escalating to engineering.

The Bottom Line

Accounting integrations aren't optional anymore. If your product touches financial data, your customers expect it to connect to their accounting system.

You can spend engineering years building and maintaining direct connections. Or you can use a unified API to launch in weeks and expand coverage as you grow.

The days of "export to CSV" are ending. Give customers the integration, or watch them find a product that does.

Frequently Asked Questions

How long does an accounting integration take to build in-house?

It depends on the platform and your requirements. Simple read-only integrations might take 4-6 weeks. Bidirectional sync with error handling, rate limiting, and multi-entity support typically takes 3-6 months. If the vendor requires a partnership agreement (NetSuite, SAP), add 3-12 months for paperwork alone.

How much do accounting integrations cost?

Direct builds run $10,000-$50,000 per integration annually when you factor in engineering time, maintenance, and support. Unified API providers typically charge $500-$2,000/month for access to dozens of integrations. The break-even point is usually 2-3 integrations.

What are the most popular accounting systems to integrate with?

Varies by segment:

SMB: QuickBooks Online, Xero, FreshBooks, Wave
Mid-market: Sage Intacct, NetSuite, Microsoft Dynamics 365 Business Central
Enterprise: NetSuite, SAP, Oracle, Microsoft Dynamics 365 Finance

What data typically gets synced?

Common objects include: invoices, bills, payments, journal entries, chart of accounts, customers/vendors, tax rates, tracking categories, purchase orders, and bank transactions. Advanced use cases add balance sheets, income statements, and aged receivables/payables.

Can I start with one integration and add more later?

Yes, but plan your data model carefully. If you build for QuickBooks first with a QuickBooks-specific schema, adding Xero later means refactoring. Starting with a normalized data model (or using a unified API) avoids this trap.

Go Deeper: Related Guides

Building your first integration?

Evaluating build vs. buy?

Designing for scale and reliability?

Understanding the Sage ecosystem?

Specific use cases?

Ready to add accounting integrations to your product? Explore Apideck's Unified Accounting API: one integration, 20+ accounting platforms, live in days.

Top Fintech APIs for Startups

𝚂𝚊𝚞𝚛𝚊𝚋𝚑 𝚁𝚊𝚒 — Thu, 05 Mar 2026 04:47:04 +0000

Building a fintech product means making critical infrastructure decisions early. The APIs you choose determine your technical debt, compliance burden, and ability to scale for years to come.

Instead of listing 20 APIs with shallow descriptions, this guide breaks down the fintech API landscape by actual business need, explains the hidden integration trade-offs, and shows you when unified API solutions prevent the maintenance nightmare that derails most startups.

The Financial Impact of API Strategy

The global open banking market is projected to reach $135.17 billion by 2030. McKinsey estimates AI could enable $1 trillion in global banking revenue shifts by the same year. These projections drive the infrastructure decisions startups make today.

But here's what those projections don't capture: most startups fail at integrations not because they chose the wrong APIs, but because they underestimated the maintenance burden.

Every API you integrate directly means authentication logic to maintain, rate limiting to handle, breaking changes to absorb, and data normalization to manage. A simple feature like "sync transactions" becomes a switch statement with fifteen cases when you're managing Stripe, Plaid, QuickBooks, and three other providers. Each case handles auth differently, maps fields uniquely, and fails in its own way.

Your codebase fragments into provider-specific branches. API providers don't coordinate their breaking changes. Plaid updates its transaction categorization. Stripe changes their webhook format. QuickBooks modifies its OAuth flow. Your test matrix explodes, but coverage remains incomplete because you can't predict every interaction.

The Money Movers: Payments and Transfers

Payment Processing

Stripe remains the default choice for startups. It handles card payments, ACH transfers, subscriptions, and payouts with a developer experience that sets the industry standard. The platform powers millions of businesses across 50+ countries, supporting companies from early-stage startups to enterprises like Amazon and Shopify.

Stripe's real advantage is the ecosystem. Stripe Treasury embeds banking features directly into products, including FDIC-insured deposits, cards, and interest-earning balances. Shopify, Lyft, and Deel use this infrastructure to manage financial accounts at scale. For startups building platforms, Stripe Connect handles marketplace payments and seller onboarding.

Adyen targets enterprise-grade needs with global payment processing across 200+ countries. For startups building for international markets from day one, Adyen's unified commerce approach handles in-person and online payments through a single integration. The tradeoff is complexity; Adyen's learning curve is steeper than Stripe's.

Square works well for startups serving physical retail or SMB markets with its point-of-sale integration and straightforward pricing. The hardware ecosystem (terminals, readers) makes it attractive for omnichannel commerce.

ACH and Bank Transfers

Dwolla excels at ACH payments with instant bank-to-bank transfers, wallet-based flows, and high-volume payouts. Payroll apps, lending platforms, and B2B marketplaces rely on this infrastructure. Dwolla handles the compliance complexity of moving money between bank accounts at scale.

Modern Treasury solves the reconciliation problem. When your startup handles large financial flows, matching payments to invoices across multiple sources becomes a full-time job. Modern Treasury automates payment ops, real-time reconciliation, and ledgering across ACH, RTP, and wire transfers. It's built for companies where money movement is core to the product.

The Data Layers: Banking Connectivity and Identity

Banking Data and Account Connectivity

Plaid dominates this category, connecting applications to thousands of banks and credit unions. Its API provides normalized financial data, including balance checks, transaction histories, account authentication, and identity verification. Personal finance apps use Plaid for spending insights, lenders use it for credit risk assessments, and neobanks integrate it for instant account verification. For teams tracking open banking APIs across different regions, the Open Banking Tracker provides data on 3,200+ open banking and PSD2 APIs globally. It helps understand coverage gaps when expanding internationally.
MX offers a strong alternative for data enrichment and transaction categorization. Personal finance management products benefit from MX's cleansing and analytics capabilities beyond basic connectivity.
TrueLayer focuses on open banking and PSD2-compliant services in Europe with instant account-to-account payments and financial insights. If your primary market is the UK or EU, TrueLayer's regional expertise matters.
Yodlee connects to over 16,000 global data sources. Wealth management apps integrate Yodlee for consolidated portfolio views, while lenders use it to assess customer liabilities before loan approval.

Identity Verification and KYC

Onfido handles government ID verification, facial recognition, liveness detection, and fraud detection. Regulatory compliance determines whether you can operate, making this category critical for any fintech handling customer funds.
Alloy powers automated risk checks by pulling data from bureaus and identity networks. Banks and neobanks use Alloy's risk engine to approve users with less manual review while maintaining compliance. The decisioning workflow builder lets you customize approval logic without code changes.
Sardine uses behavioral biometrics and machine learning to catch what traditional checks miss: suspicious login attempts, unusual spending patterns, device spoofing, and account takeovers. If your app handles money movement, Sardine adds a protection layer that document verification alone can't provide.

The Back Office: Accounting, ERP, and HRIS

This is where most startups underestimate complexity.
The challenge isn't just connecting to one accounting system. It's that your customers use different systems. QuickBooks, Xero, NetSuite, Sage, FreshBooks, and dozens of regional platforms each have distinct authentication flows, data models, rate limits, and field mapping requirements.
What looks like "add QuickBooks integration" on a roadmap becomes a three-month project. Then customers ask for Xero. Then, enterprise prospects require NetSuite. Each integration multiplies your maintenance burden. Your engineers become integration specialists rather than product developers.

Accounting and ERP Integration

QuickBooks Online holds approximately 80% market share among US small businesses. If you're serving American SMBs, QuickBooks integration is expected. But Intuit's API has authentication quirks, sandbox limitations, and data models that require dedicated engineering time to handle correctly.
Xero dominates the SME market in Australia, the UK, and New Zealand. International expansion means another separate integration with different conventions.
NetSuite and Sage Intacct serve mid-market and enterprise customers with multi-entity structures and complex financial requirements. These integrations are significantly more complex than SMB accounting platforms. Multi-subsidiary consolidation, custom fields, and approval workflows add implementation time. For detailed guidance on accounting API selection, see Top 15 Accounting APIs to Integrate with in 2025.

The Unified API Alternative

This is where unified API platforms become relevant. Instead of building and maintaining separate integrations for each accounting system, unified APIs let you connect once and access multiple platforms through a standardized interface.

The approach trades some customization depth for dramatically reduced maintenance. You lose access to provider-specific advanced features, but you gain consistent data models, centralized authentication, and a single codebase instead of 15.

Apideck's Accounting API is one solution in this space alongside Kombo, Finch, and Merge, providing access to 20+ accounting systems through a single integration. For implementation details on handling expenses and bills across platforms, see Integrating Expenses and Bills with the Accounting API.

HRIS and Payroll Integration

Fintech products increasingly touch workforce data for payroll integrations, employee verification, or benefits administration. Gusto, ADP, BambooHR, Rippling, and Workday each require separate integrations with distinct APIs and authentication flows.

Unified HRIS APIs normalize employee data across these platforms. Payroll automation through standardized integrations allows companies to scale without additional engineering investment per provider.

Lending and Investment APIs

Lending and Credit

Experian provides credit scoring and risk assessment through its credit bureau database, delivering real-time credit histories and fraud checks. BNPL providers and underwriting platforms use it for risk-based decisioning.
Finicity (now part of Mastercard) offers cash flow analytics and income verification, replacing paper-based income proofs for mortgage lenders and personal loan providers. The shift to real-time income verification is accelerating across lending categories.

For embedded lending use cases, see From Accounts Receivable to Lending Automation.

Investment and Trading

Alpaca offers commission-free trading APIs for developers building trading apps and algorithmic platforms. Its startup-friendly approach and documentation quality make it accessible for early-stage fintech.
Polygon.io provides stock market data, news, and analysis for investment platforms and trading apps that need real-time market information.

Embedded Finance Considerations

Non-financial companies are embedding payments, lending, insurance, and banking features into their products. This isn't a future trend; it's the current expectation across industries.

Vertical SaaS platforms add financial workflows to increase stickiness and revenue per customer. Construction software embeds equipment financing tied to project milestones. Healthcare platforms offer working capital based on insurance receivables. Restaurant systems provide cash advances against future credit card sales.
Marketplaces offer seller financing and instant payouts to attract supply-side participants. HR platforms embed earned wage access and benefits management to differentiate their offerings.

Building embedded finance requires integrations across accounting, banking, payments, and lending APIs. This is where unified APIs provide the most value by reducing the integration surface area while maintaining breadth of coverage. The technical burden extends beyond initial implementation; each category adds compliance surface area and ongoing maintenance.

When to Use Direct vs. Unified APIs

Every API integration increases your compliance surface area. Financial data requires SOC 2 compliance, data residency controls, and comprehensive audit trails. This context matters when evaluating the direct vs. unified decision.

Direct integrations make sense when:

Your entire business runs on one provider, and you need every advanced feature
You have dedicated integration engineers for long-term maintenance
You're pre-product-market-fit and only need one or two integrations
Your competitive advantage depends on deep optimization for a specific platform

⠀Unified APIs make sense when:

Customers demand multiple integrations across a category
Engineering time goes to integration maintenance instead of product development
You need enterprise integrations (NetSuite, SAP, Workday) without enterprise engineering overhead
You're scaling rapidly and can't afford three-month integration projects for each new provider

⠀For detailed analysis, see Unified APIs for Fintech: When Point Integrations Stop Scaling.

Recommended Stacks by Product Type

Neobank: Plaid + Unit or Stripe Treasury + Onfido + Unified Accounting API
Lending platform: Plaid + Experian/Finicity + Alloy + Dwolla + Unified Accounting API
Expense management: Stripe + Unified Accounting API + Unified HRIS API
Vertical SaaS with financial features: Stripe + Unified Accounting API + Unified HRIS API

Next Steps

Fintech API strategy isn't about choosing the "best" APIs. It's about building an integration architecture that scales without consuming engineering capacity.

Direct integrations make sense for core payment and banking infrastructure, where you need deep control. Unified APIs make sense for customer-facing integrations that require breadth without maintenance overhead.
The startups that scale treat integrations as strategic infrastructure rather than feature checkboxes.

Stripe has been doing amazing work with their llms.txt, and this guide covers it well. This might be worth adding to your own llms.txt file too!

𝚂𝚊𝚞𝚛𝚊𝚋𝚑 𝚁𝚊𝚒 — Thu, 05 Mar 2026 04:42:34 +0000

Gertjan De Wilde for Apideck

Mar 5

Stripe's llms.txt has an instructions section. That's a bigger deal than it sounds.

#ai #agents #dx #webdev

Comments 3

8 min read

5 Portfolio Templates You Can Deploy Tonight (No React Experience Required)

𝚂𝚊𝚞𝚛𝚊𝚋𝚑 𝚁𝚊𝚒 — Tue, 27 Jan 2026 07:05:00 +0000

A recruiter clicks your GitHub link. She sees "test-app", "my-portfolio" (last updated 2022), and "ml-project-final-FINAL". She's not going to clone your repo to figure out what you built. Tab closed. Next candidate.

Recruiters need a URL they can paste into Slack and share with their Hiring Managers. Give them one.

Here are five open-source templates all in Astro. Each deploys in under an hour.

1. Astro Terminal Theme: Nostalgia That Ships

GitHub: https://github.com/dennisklappe/astro-theme-terminal

A terminal-style theme ported from the popular Hugo Terminal Theme. Monospace fonts, retro color schemes, and blinking cursors. All the developer aesthetic without any of the fragility.

This works for people who want to signal "I actually write code" without building a custom portfolio from scratch. The terminal look filters out recruiters who don't get developer culture. The ones who stay are looking for engineers.

Why recruiters care:

Syntax-highlighted code blocks prove you understand presentation
Dark theme with customizable colors shows attention to detail
RSS feed built in, so your blog posts reach people who use RSS readers (read: technical decision-makers)

⭐️ Astro Terminal Theme on GitHub

2. Angie: Bold Brutalism

GitHub: https://github.com/anthonylan/angie

Brutalist design with thick borders, stark contrast, and zero apologies. Built with TailwindCSS and GSAP animations. This isn't a safe choice. That's the point.

Use this if you're tired of portfolios that look like everyone else's. Angie grabs attention because it refuses to blend in. The visual punch forces recruiters to actually look at your work instead of skimming past.

Why recruiters care:

GSAP animations show you understand interaction design
Strong visual hierarchy guides eyes exactly where you want them
Stands out in a sea of minimal-to-the-point-of-invisible portfolios

⭐️ Angie on GitHub

3. macOS Portfolio: The Conversation Starter

GitHub: https://github.com/aabdoo23/portfolio

A macOS desktop simulation with draggable windows, a working dock, and an AI-powered terminal you can actually chat with. Projects, notes, resume viewer, Spotify integration. The whole operating system fantasy.

This exists for people who want their portfolio to feel like an experience. Recruiters will click around because it's genuinely fun. The AI terminal lets visitors ask questions about you when you're not there to answer.

Why recruiters care:

Shows frontend skills that go beyond "I can center a div"
Interactive elements increase time-on-page, which means they're actually reading your work
AI chat answers questions about you 24/7

⭐️ macOS Portfolio on GitHub

4. Minimalist CV: One Page, Zero Excuses

GitHub: https://github.com/ZhukDI/cv

Single config file. Edit your data in one TypeScript file, build, deploy. Print-optimized layouts render perfectly on paper. Zero client-side JavaScript.

Use this if your resume keeps getting compliments but your portfolio keeps getting ignored. Minimalist CV bridges the gap. Same clean formatting recruiters love on paper, now available as a URL they can share.

Why recruiters care:

Print styles mean they can hit Cmd+P and hand your resume to a hiring manager
All your info in one config file means updates take 30 seconds
Loads instantly because there's nothing to load

⭐️ Minimalist CV on GitHub

5. Brutal: Neobrutalist, No JavaScript

GitHub: https://github.com/eliancodes/brutal

Built by an Astro core team member. Neobrutalist design with bold colors, hard shadows, and clean typography. Ships with RSS, sitemap, and image optimization out of the box. No JavaScript by default.

This works for people who want something opinionated but production-ready. Brutal doesn't ask you to make design decisions. The decisions are made. You fill in your content and deploy.

Why recruiters care:

SEO optimized from the start, so they can actually find you
Blog section proves you can communicate technical ideas in writing
Fast load times because JavaScript isn't slowing anything down

⭐️ Brutal on GitHub

Before You Deploy

A portfolio gets recruiters interested. Your resume gets you past ATS filters into the interview.

⭐️ Resume Matcher on GitHub

If you're still getting ghosted after applying, the problem isn't your portfolio. It's your resume using words the ATS doesn't recognize. I built Resume Matcher to fix that. It rewrites your resume to match job descriptions so you stop guessing which keywords get you rejected.

I build open-source tools for job seekers. Follow me for Part 3: free AI/ML learning paths from Microsoft.

Now stop reading and go deploy.

5 Open-Source Resume Builders That'll Help Get You Hired in 2026

𝚂𝚊𝚞𝚛𝚊𝚋𝚑 𝚁𝚊𝚒 — Wed, 21 Jan 2026 15:53:41 +0000

75% of resumes get deleted by software before a human sees them. Not rejected. Deleted. The recruiter never knew you existed.

This happens because Applicant Tracking Systems parse resumes for keywords. Your resume says "built backend systems." The job posting says "developed REST APIs." Same work. Wrong words. Deleted.

Here are five free tools that fix this. Each solves a different problem. I'll tell you which one to use based on where you're stuck.

1. Resume Matcher — If You Keep Getting Ghosted

GitHub: https://github.com/srbhr/Resume-Matcher

Best for: People who apply to dozens of jobs and hear nothing back.

I built this because I was mass-applying and getting auto-rejected from roles I was qualified for. The problem was obvious once I saw it: my resume used different words than the job posting. ATS doesn't do synonyms.

Resume Matcher takes your master resume and a job description, then rewrites your resume to match. Not keyword stuffing. Actual rewriting. You edit the output, then download a PDF that parsers can read.

Why it works:

Find the missing keywords that get you rejected
Rewrites your resume so you stop guessing what ATS wants
Four templates that parsers actually read without choking

⭐️ Resume Matcher on GitHub

2. Reactive Resume — If You Need a Resume Fast and Free

GitHub: https://github.com/amruthpillai/reactive-resume

Best for: People who need a working resume tonight without paying for Canva Pro.

Most resume builders bait you with free design, then put a paywall on the PDF export. Reactive Resume is fully open-source. No account. No watermark. No $15/month ransom for your own document.

Why it works:

Download your PDF without creating an account or paying
Export to JSON so you can version control with Git
Templates designed for ATS parsing, not Instagram screenshots

⭐️ Reactive Resume on GitHub

3. OpenResume — If You Want to Test Your Current Resume

GitHub: https://github.com/xitanggg/open-resume

Best for: People who already have a resume and want to check if ATS can read it.

OpenResume has a parser. Upload your existing resume and watch what it extracts. If the parser mangles your job titles or misses your skills section, the ATS will do the same. Use it as a diagnostic before you apply anywhere.

Why it works:

Parser shows you exactly what ATS sees (and misses)
Runs in your browser with zero data sent to servers
Builder included if your current resume fails the test

⭐️ OpenResume on GitHub

4. RenderCV — If You Want Version Control

GitHub: https://github.com/rendercv/rendercv

Best for: Engineers who want to manage their resumes like codebases.

Your resume content lives in a YAML file. Run a command. Get a PDF. Track changes in Git. Diff versions. Roll back mistakes. Switch templates by editing one line instead of reformatting the whole document.

Why it works:

Git history for every change you make
Template swaps without touching your content
LaTeX rendering that looks sharp, not like a Word doc

⭐️ RenderCV on GitHub

5. LapisCV — If You Live in Markdown

GitHub: https://github.com/BingyanStudio/LapisCV

Best for: People who already use Obsidian, Typora, or VSCode for everything.

Write your resume in Markdown. Export to PDF. That's it. No new interface to learn. If you take notes in Markdown, write docs in Markdown, and manage your life in Markdown, your resume should live there too.

Why it works:

Works inside tools you already use daily
Edit text, see PDF update immediately
Version control is trivial since it's just a text file

⭐️ LapisCV on GitHub

The Decision

Stuck in application black holes? Resume Matcher.

Need a resume built for free tonight? Reactive Resume.

Want to diagnose why your current resume isn't working? OpenResume.

Prefer managing documents like code? RenderCV.

Already living in Markdown? LapisCV.

Pick one. Build your resume. Apply to jobs. Stop optimizing which tool to use.

What's Next

Hey, I'm Saurabh Rai. I write about open-source tools, job hunting, and building in public. If this was useful, follow me on DEV to catch the next post in this series covering portfolio templates that actually get you interviews.

And if you're tired of guessing why applications disappear, give Resume Matcher a try. It's free, it's open-source, and I built it because I was stuck in the same rejection loop.

⭐️ Star Resume Matcher on GitHub

Now stop reading and go fix your resume.

AI Psychosis

𝚂𝚊𝚞𝚛𝚊𝚋𝚑 𝚁𝚊𝚒 — Fri, 21 Nov 2025 11:51:10 +0000

AI psychosis (n.): A dissociative state in which reality is experienced not directly, but as prompts to be engineered; life becomes a series of queries awaiting AI response.

[5:31 AM] The morning starts with my phone, I open up Claude and text, “Good Morning!” and wait for a warm response at the end of ‘thinking’

[5:34 AM] Standing in front of a balcony, I don’t see a sunrise, I see: “An image of the sun, morning, dawn, orange yellow rays coming from the bottom, sky is darker at the top, and there are trees, dimly lit.” Things move from experiencing to, I can prompt this up… I can create this with AI, that too. Everything is now a prompt, and everything is AI for you.

[6:03 AM] I share my schedule with Claude and ask what the perfect time is to have coffee to energize my morning routine. What should I have for breakfast?

[7:44 AM] as time passes and I switch on to work… I hop from one AI to another AI in terms of getting a novel response. Like pulling a lever, searching for prompts, and modifying prompts. Looking out for that “one master prompt to solve it all.” I go from ChatGPT to Claude to Gemini to Grok to those Chinese AI models, thinking that if this one provides a better response, you’ll switch between models to see a 1% improvement. There’s something on the screen that I’m interacting with. Typing, thinking, and my notepad, full of prompts. Something’s cooking… I’m not sure what it is.

[1:15 PM] “Hey Claude, after having eggs and garlic bread for breakfast, what should I have for lunch?” And in between each bite of food, I share jokes with Gemini and ChatGPT, and then share those screenshots with Claude, asking it to roast them.

[2:33 PM] back to work … “What’s the best way to transcribe meeting notes so that I can catalog them and make sure that they’re part of my second brain. I don’t want to miss anything that’s being said in the meeting, and yes. Please use the Notion MCP to create tasks from those meetings and add them to a page.”

[5:55 PM] Fighting between which AI writes the best code, “You’re absolutely right. According to the benchmarks, Claude Sonnet’s code is more trustworthy,” says Claude Opus-4.1, but then I think GPT-5 has written cleaner code with minimal edits.

[6:06 PM] I’ve been working for 12 hours… this feels like a productive day, pure grinding, from one AI to another. I think after eight drafts and 3 code edits, I’m done for the day. Nothing is committed yet. Everything is in progress. Maybe this is the “progress” everyone is talking about. AI will take us forward to the point where everything remains in progress.

[8:18 PM] A thought appears, When was the last time I had a conversation with a human, in real life? But at the same time, Claude stops thinking and shares my daily productivity insights. I’m 81% productive today, and lectures me on where I can improve. Maybe this is life ❣︎

Where's the notification icon 🤔 I don't see it anymore.

𝚂𝚊𝚞𝚛𝚊𝚋𝚑 𝚁𝚊𝚒 — Tue, 04 Nov 2025 08:50:47 +0000

A Guide to Integrating with the NetSuite REST API

𝚂𝚊𝚞𝚛𝚊𝚋𝚑 𝚁𝚊𝚒 — Fri, 31 Oct 2025 14:28:04 +0000

A Guide to Integrating with the NetSuite REST API

Accounting systems like NetSuite are the backbone for managing and optimizing business operations through automated processes and integrated workflows. NetSuite is a cloud-based enterprise resource planning (ERP) system that provides a business software suite for financial management, customer relationship management, e-commerce, and more.

The NetSuite REST API allows developers to build modern integrations that connect NetSuite to other systems, automate complex workflows, and synchronize data across different platforms. Using this API, developers can automate tasks such as customer creation, order processing, and real-time inventory updates. This is key to building automated solutions that reduce manual effort and increase accuracy.

Why the NetSuite REST API Matters

The NetSuite REST API provides a modern, JSON-based interface to NetSuite's core functionality, allowing you to interact with the platform programmatically using standard HTTP methods. You can use it to perform operations such as creating and updating records, managing customer data, processing transactions, and retrieving financial reports. The REST API enables you to integrate NetSuite into your existing systems and automate business-critical processes while ensuring data consistency across all applications.

For example, you can automate workflows like customer onboarding or sync order data between NetSuite and external platforms, reducing manual errors and increasing operational efficiency.

NetSuite SOAP API Alternative

If you're evaluating NetSuite integration options, you might also consider the NetSuite SOAP API. While SOAP is more established and offers broader functionality coverage, it's significantly more complex to implement due to XML handling and verbose request structures. For a detailed comparison and implementation guide, see our comprehensive NetSuite SOAP API integration guide.

Here are some examples of how you can use the REST API:

Automating customer management: The NetSuite REST API can automatically create customer records when new users sign up on your website, sync contact information, and update customer data across systems. This eliminates duplicate data entry and ensures customer information stays current across all touchpoints.

Real-time inventory synchronization: The REST API can integrate with e-commerce platforms like Shopify or WooCommerce to provide real-time inventory updates. When a product is sold online, the API immediately updates stock levels in NetSuite and can trigger reorder notifications when inventory falls below threshold levels.

Automated financial reporting: The REST API can integrate with business intelligence tools to generate real-time financial dashboards. This automation provides up-to-date profit and loss statements, cash flow reports, and sales analytics, helping businesses make data-driven decisions quickly.

How to Integrate with the NetSuite REST API

NetSuite's REST API supports Token-Based Authentication (TBA) and OAuth 2.0 for secure API access.

This guide focuses on Token-Based Authentication, which involves creating a signature using your NetSuite account credentials and including it with other authentication parameters in the request headers.

To interact with the REST API, you need to:

Create a user role with appropriate permissions, including REST Web Services access
Create a new integration record for token-based authentication and obtain the consumer key and secret
Create a new access token and obtain the token ID and secret

More detailed information is available in the official documentation.

Simplify Authentication with Apideck Vault

The authentication setup process above can be complex and time-consuming for your end users. Apideck Vault provides a white-label, hosted authentication interface that eliminates this complexity entirely.

With Vault, your users can:

Connect NetSuite in seconds - No technical setup required on their end
Secure credential storage - OAuth tokens and API keys are stored safely with enterprise-grade security
Unified experience - Same interface works for NetSuite, QuickBooks, Xero, and 200+ other integrations
Self-service management - Users can connect, disconnect, and manage integrations independently

Instead of asking users to create integration records and access tokens, they simply authenticate through Vault's hosted interface. You get the integration data you need without the setup friction that kills conversion rates.

Making a Request to the NetSuite REST API

The base URL for NetSuite REST API requests follows this format:
https://{account_id}.suitetalk.api.netsuite.com/services/rest/record/v1/{record_type}

NetSuite uses OAuth 1.0a for authentication, which requires generating a signature for each request. Here's a Python example:

import requests
from requests_oauthlib import OAuth1

# NetSuite credentials
account_id = "your_account_id"
consumer_key = "your_consumer_key" 
consumer_secret = "your_consumer_secret"
token_key = "your_token_key"
token_secret = "your_token_secret"

# Create OAuth1 auth object
auth = OAuth1(
    consumer_key,
    client_secret=consumer_secret,
    resource_owner_key=token_key,
    resource_owner_secret=token_secret,
    signature_method='HMAC-SHA256',
    signature_type='AUTH_HEADER'
)

# Example: Get a customer record
def get_customer(customer_id):
    url = f"https://{account_id}.suitetalk.api.netsuite.com/services/rest/record/v1/customer/{customer_id}"

    headers = {
        'Content-Type': 'application/json'
    }

    response = requests.get(url, auth=auth, headers=headers)
    return response.json()

# Example: Create a customer record
def create_customer(customer_data):
    url = f"https://{account_id}.suitetalk.api.netsuite.com/services/rest/record/v1/customer"

    headers = {
        'Content-Type': 'application/json'
    }

    response = requests.post(url, auth=auth, headers=headers, json=customer_data)
    return response.json()

# Usage examples
try:
    # Get customer with ID 123
    customer = get_customer("123")
    print("Customer data:", customer)

    # Create a new customer
    new_customer = {
        "companyName": "Acme Corporation",
        "email": "contact@acme.com",
        "phone": "+1-555-0123"
    }

    result = create_customer(new_customer)
    print("Created customer:", result)

except Exception as error:
    print("Error making API request:", error)

The Integration Challenge

As you can see from the examples above, integrating directly with the NetSuite REST API involves several challenges:

Authentication complexity: Implementing OAuth 1.0a signature generation requires precise handling of encoding, sorting, and hashing
Rate limiting management: NetSuite has strict concurrency limits that require careful request throttling to avoid timeouts
Custom field handling: NetSuite's custom fields require specific formatting and field ID mapping that varies by account
Error handling complexity: NetSuite's error responses require specific parsing and retry logic for different error types
Data transformation: NetSuite's data structures often don't match your application's data models
Pagination complexity: Handling large datasets requires implementing cursor-based pagination logic
Webhook limitations: NetSuite's webhook support is limited, requiring polling for real-time data needs

Each of these challenges adds development time and increases the potential for bugs in your integration.

The Apideck Unified Accounting API

Integrating with multiple accounting systems, including NetSuite, can be overwhelming and time-consuming. Managing OAuth signatures, handling rate limits, and dealing with different data formats across various platforms requires months of development effort and ongoing maintenance.

The Apideck Unified Accounting API provides a single integration point for 20+ accounting platforms, including NetSuite. This approach abstracts away the complexities of individual APIs, simplifying the integration process.

Key benefits of using the Apideck Unified Accounting API include:

Real-time data processing: All API calls are processed in real-time, not batched, ensuring your data is always fresh
Managed authentication with Vault: Apideck Vault handles all OAuth flows and credential management, eliminating complex authentication setup for your users
Unified data model: Consistent data structures across all 18+ accounting platforms
Built-in rate limit management: Automatic throttling and retry logic with exponential backoff
Webhook emulation: Get push notifications from platforms that support webhooks, with Apideck emulating webhooks for platforms that don't
White-label user interface: Easily embedded interface that gives users a simple and secure connection experience
Data normalization: Messy, inconsistent APIs are normalized into a single structure while still exposing raw downstream information
Reduced maintenance burden: Updates to underlying accounting systems don't require changes to your integration

Making Requests with Apideck

Before making API requests through Apideck, you need to configure your NetSuite connection in the Apideck platform.

Here's how simple the same operations become with Apideck's unified API. You can try these requests in our Api Explorer, which makes this even simpler.

import axios from "axios";

const headers = {
  "x-apideck-app-id": "<YOUR-APP-ID>",
  "Authorization": "Bearer <YOUR-API-KEY>",
  "x-apideck-consumer-id": "<CONSUMER-ID>", // Your NetSuite consumer
  "Content-Type": "application/json"
};

// Get a customer - unified across all accounting platforms
async function getCustomer(customerId: string) {
  try {
    const response = await axios.get(
      `https://unify.apideck.com/accounting/customers/${customerId}`,
      { headers }
    );
    return response.data;
  } catch (error) {
    console.error("Error retrieving customer:", error);
  }
}

// Create a customer - same API call works for NetSuite, QuickBooks, Xero, etc.
async function createCustomer(customerData: any) {
  try {
    const response = await axios.post(
      "https://unify.apideck.com/accounting/customers",
      customerData,
      { headers }
    );
    return response.data;
  } catch (error) {
    console.error("Error creating customer:", error);
  }
}

// List all invoices with automatic pagination
async function getInvoices() {
  try {
    const response = await axios.get(
      "https://unify.apideck.com/accounting/invoices",
      { headers }
    );
    return response.data;
  } catch (error) {
    console.error("Error retrieving invoices:", error);
  }
}

// Usage examples
const customer = await getCustomer("123");
console.log("Customer:", customer);

const newCustomer = {
  name: "Acme Corporation",
  email: "contact@acme.com", 
  phone_number: "+1-555-0123"
};

const createdCustomer = await createCustomer(newCustomer);
console.log("Created customer:", createdCustomer);

const invoices = await getInvoices();
console.log("Invoices:", invoices);

Here’s an example of the same request from Apideck’s API Explorer

You can test and make API calls with the simple drag and drop UI, which can easily pre-fill the response headers and body with the required data. You can see the list customers request being done in a single shot.

Compare this clean, simple code to the complex OAuth signature generation and authentication handling required for direct NetSuite integration. With Apideck, the same code works across NetSuite, QuickBooks, Xero, Sage, and dozens of other accounting platforms.

Real-World Integration Examples

Here are some practical examples showing how Apideck simplifies common NetSuite integration scenarios. Please note, you can try them out from our Api Explorer.

E-commerce Order Sync:

// Sync new orders from your e-commerce platform to NetSuite
async function syncOrderToNetSuite(order: any) {
  const invoice = {
    number: order.order_number,
    customer: { id: order.customer_id },
    line_items: order.items.map(item => ({
      description: item.name,
      quantity: item.quantity,
      unit_amount: item.price,
      item: { id: item.product_id }
    })),
    due_date: new Date(Date.now() + 30 * 24 * 60 * 60 * 1000).toISOString()
  };

  return await axios.post(
    "https://unify.apideck.com/accounting/invoices",
    invoice,
    { headers }
  );
}

Customer Data Synchronization:

// Keep customer data in sync between your CRM and NetSuite
async function syncCustomerData(crmCustomer: any) {
  const customer = {
    name: crmCustomer.company_name,
    email: crmCustomer.primary_email,
    phone_number: crmCustomer.phone,
    billing_address: {
      line1: crmCustomer.billing_street,
      city: crmCustomer.billing_city,
      state: crmCustomer.billing_state,
      postal_code: crmCustomer.billing_zip,
      country: crmCustomer.billing_country
    }
  };

  return await axios.post(
    "https://unify.apideck.com/accounting/customers",
    customer,
    { headers }
  );
}

Conclusion

In this guide, you learned how to integrate with the NetSuite REST API and discovered the complexities involved in direct integration. As demonstrated, working directly with NetSuite's API requires managing complex OAuth 1.0a signatures, handling rate limits, dealing with custom field mappings, and maintaining error-prone authentication code.

These challenges multiply when you need to support multiple accounting platforms beyond NetSuite. Each system has its own authentication methods, data structures, and API quirks that require separate implementations and ongoing maintenance.

To simplify your accounting integrations and eliminate the complexities of direct API integration, consider using the Apideck Unified Accounting API with the NetSuite Connector. By providing a single, consistent interface across all major accounting platforms, Apideck simplifies development, reduces maintenance overhead, and saves valuable development time and resources.

With Apideck, you can:

Connect to NetSuite and 20+ other accounting platforms with the same code
Skip complex authentication implementations
Get standardized data models across all platforms
Benefit from built-in rate limiting and error handling
Access real-time data processing (not batch processing)
Use webhook emulation for platforms that don't natively support webhooks
Focus on building features instead of managing integrations

Frequently Asked Questions

What's the difference between NetSuite REST API and SOAP API?

The REST API is newer (2019), uses JSON, and is easier to implement, but has limited functionality coverage. The SOAP API has been around longer, offers broader NetSuite feature access, but requires XML handling and is more complex to implement. For bulk operations and advanced features, SOAP is often better. For modern web/mobile apps and simple CRUD operations, REST is preferred. See our SOAP API guide for a detailed comparison.

How do I handle NetSuite's rate limits?

NetSuite uses concurrency-based rate limiting rather than traditional rate limits. Each account has a limit on concurrent API requests (typically 10-25 concurrent requests). When you exceed this limit, you'll get timeout errors rather than 429 rate limit errors. Implement exponential backoff retry logic and consider queuing requests during high-traffic periods. Monitor your usage through NetSuite's API monitoring tools.

Can I use OAuth 2.0 with NetSuite REST API?

Yes, NetSuite supports OAuth 2.0 for REST API authentication, but Token-Based Authentication (TBA) is more commonly used because tokens don't expire like OAuth 2.0 access tokens do. OAuth 2.0 requires refresh token management and has a 7-day refresh limit, making TBA more suitable for server-to-server integrations. However, if you need user-facing authentication flows, OAuth 2.0 is the better choice.

DATEV API Integration: A Comprehensive Technical Guide

𝚂𝚊𝚞𝚛𝚊𝚋𝚑 𝚁𝚊𝚒 — Fri, 31 Oct 2025 14:27:33 +0000

When German businesses need accounting software, they turn to DATEV. With decades of market dominance and adoption by thousands of tax consultants across Germany, DATEV has become the de facto standard for financial record-keeping in the German market. But here's where things get interesting for developers: integrating with DATEV isn't like connecting to your typical REST API. The architecture is fundamentally different, and understanding these differences is critical to building a successful integration.

If you're building an ERP system, e-commerce platform, or any business application that needs to sync financial data with German accounting workflows, you'll need to understand how DATEV integration actually works. This guide will walk you through the technical architecture, explain why DATEV takes a batch-processing approach instead of real-time REST calls, and show you the practical steps for implementing a robust integration.

Understanding DATEV API Integration

DATEV API integration connects your third-party platform to DATEV's accounting software ecosystem, enabling automated synchronization of financial data without manual file imports or error-prone copy-paste workflows. When you integrate with DATEV, you're connecting to the systems used by tax consultants and accountants across Germany to manage client finances, prepare tax filings, and maintain compliance with German accounting regulations.

The typical use cases span multiple business domains. E-commerce platforms sync order data and payment records. Banking systems push transaction updates for reconciliation. Property management software sends rent payments and tenant invoicing data. Payroll systems transfer employee expense information. In each case, the goal is the same: eliminate manual data entry, reduce errors, and enable real-time visibility into financial operations.

What makes DATEV integration valuable is the automation of repetitive accounting tasks. Instead of your accountant manually importing CSV files and checking for discrepancies, your integration automatically creates properly formatted records that flow directly into the accounting workflow. Invoice data, customer and supplier records, journal entries, cost center allocations, and VAT calculations all sync automatically. The result is enhanced compliance with German accounting regulations, reduced data errors, improved accuracy, and proactive financial management based on current data rather than week-old exports.

The Two Types of DATEV APIs

Here's where DATEV diverges sharply from typical API architectures. DATEV offers two primary data exchange formats, and neither one works like the REST or SOAP APIs you're probably familiar with. Understanding this distinction is absolutely critical before you start building your integration.

The CSV-based API, used for DATEV Rechnungswesen (abbreviated as ReWe), handles finalized financial bookings and accounting records. When you need to submit completed transactions that are ready for the permanent accounting record, you use this approach. Data flows through flat, tabular CSV files that must follow precise column formatting requirements. These files are processed through batch jobs called EXTF-Jobs. This approach is common in on-premise environments and legacy integrations where the infrastructure was built before cloud-native architectures became standard.

The XML-based API, used for DATEV Unternehmen Online (abbreviated as DUo), handles booking suggestions and invoice processing. This format supports complex, hierarchical data structures that represent more nuanced financial information. Data moves through structured XML files that are validated against XSD schemas to ensure compliance. These files are processed with batch jobs called dxso-Jobs. The XML approach focuses on cloud platforms and modern workflows, particularly for scenarios where you're proposing bookings that require accountant review before finalization.

Now here's the critical point that trips up many developers: DATEV does not use traditional REST or SOAP APIs for core accounting operations. If you're expecting to make HTTP POST requests with JSON payloads and get immediate synchronous responses, you're approaching this wrong. DATEV's integration relies on asynchronous batch-based file processing. You submit files as jobs, those jobs enter a processing queue, and DATEV systems handle them on their own schedule. You cannot use typical RESTful calls for submitting bookings or financial records.

There are some exceptions worth noting. DATEV does offer REST endpoints for certain niche products. The Cash Register Import API (MeinFiskal) provides documented REST endpoints for importing electronic cash register data. The Document Management system integrates via REST APIs through DATEVconnect for document workflows. But these are specialized use cases, not the core accounting functionality.

Third-party unified API providers sometimes expose REST endpoints that make DATEV integration feel more familiar to developers. But understand what's happening under the hood: these are wrappers that translate your REST calls into DATEV's batch processing behind the scenes. The underlying architecture remains batch-based, even if the developer experience feels more REST-like.

Working with the accounting:documents API

Let me show you a practical example using the accounting:documents REST API, which handles document uploads to Belege online in DATEV Unternehmen online. This is one of the REST endpoints that DATEV provides, and it demonstrates the authentication and data handling patterns you'll encounter.

First, you need to retrieve the list of clients your authenticated user can access. This establishes which companies you have permission to integrate with:

GET https://accounting-documents.api.datev.de/platform/v2/clients
Authorization: Bearer {access_token}
X-DATEV-Client-Id: {your_client_id}

The response gives you client identifiers that you'll use in subsequent requests:

[
  {
    "client_number": 1,
    "consultant_number": 455148,
    "id": "455148-1",
    "name": "Muster GmbH 1"
  }
]

That id field is the technical identifier you'll use for all data operations. Notice that it combines the consultant number and client number, creating a unique reference for this specific client within the DATEV system.

Before uploading documents, you should check what document types are available for this client. Document types determine how DATEV processes and categorizes your uploads:

GET https://accounting-documents.api.datev.de/platform/v2/clients/455148-1/document-types
Authorization: Bearer {access_token}
X-DATEV-Client-Id: {your_client_id}

This returns the configured document types:

[
  {
    "name": "Rechnungseingang",
    "category": "invoices_received",
    "debit_credit_identifier": "debit"
  },
  {
    "name": "Rechnungsausgang",
    "category": "outgoing_invoices",
    "debit_credit_identifier": "credit"
  },
  {
    "name": "Kasse",
    "category": "other_documents"
  }
]

Now you can upload a document. This uses multipart form data to combine the file with metadata:

POST https://accounting-documents.api.datev.de/platform/v2/clients/455148-1/documents
Authorization: Bearer {access_token}
X-DATEV-Client-Id: {your_client_id}
Content-Type: multipart/form-data

--boundary
Content-Disposition: form-data; name="file"; filename="invoice-2024-001.pdf"
Content-Type: application/pdf

[Binary PDF content]
--boundary
Content-Disposition: form-data; name="metadata"
Content-Type: application/json

{
  "document_type": "Rechnungseingang",
  "note": "Supplier invoice for office supplies",
  "category": "MyERP",
  "folder": "Invoices",
  "register": "2024/10"
}
--boundary--

The metadata structure organizes documents within DATEV's document repository using a three-level hierarchy: category, folder, and register. If you specify any of these levels, you must provide all three. This organizational structure helps accountants locate documents efficiently within the DATEV interface.

When the upload succeeds, you receive confirmation with file details:

{
  "file": [{
    "name": "invoice-2024-001.pdf",
    "size": 125742,
    "upload_date": "2024-10-09T14:23:12+02:00",
    "media_type": "application/pdf"
  }],
  "document_type": "Rechnungseingang",
  "note": "Supplier invoice for office supplies"
}

Authentication and Authorization

DATEV uses OAuth2 for authorization, particularly for cloud-based integrations with Unternehmen Online. You need to design secure user consent workflows that clearly explain what data your application will access and how it will be used. Many integration scenarios require third-party approval or validation from the tax consultant who manages the client's account, since tax consultants control client access within the DATEV ecosystem.

Your OAuth implementation should support long-lived tokens with automatic renewal processes. This is critical because DATEV integrations often need continuous data synchronization without requiring users to re-authenticate frequently. Users expect their accounting data to flow automatically once they've granted initial consent.

The typical OAuth flow follows this pattern: redirect the user to DATEV's authorization endpoint, receive an authorization code after the user grants consent, exchange that code for access and refresh tokens, and use the access token for API requests. When the access token expires, use the refresh token to obtain a new access token without requiring user interaction.

Data Format Compliance and Validation

DATEV enforces strict format requirements because accounting data must maintain audit compliance and regulatory standards. The CSV and XML formats are fixed specifications that vary by product. You cannot choose arbitrary formats or invent your own column structures.

For XML submissions to Unternehmen Online, your files must validate against DATEV's XSD schemas before processing will succeed. The schemas define required fields, data types, value constraints, and structural relationships. XML validation failures result in immediate job rejection with error codes that indicate which validation rules you violated.

CSV files for Rechnungswesen demand precise column formatting. Each column must contain the correct data type in the expected position. Column order matters. Field delimiters must match the specification exactly. Even minor deviations cause processing failures because the DATEV import engine cannot risk misinterpreting financial data.

Beyond basic format validation, you must properly structure metadata that accompanies your financial records. Cost center allocations, voucher numbers, analytic account references, and VAT information all need to follow DATEV's coding schemes. German VAT codes, for instance, follow specific conventions that DATEV recognizes and validates against current tax regulations.

Common Error Scenarios

The OpenAPI specification documents numerous error codes you'll encounter. Let me walk through the most common ones and what they mean for your integration.

Error #DCO01010 restapi.InvalidDocumentTypeFault occurs when you specify a document type that doesn't exist for the client. Remember that each client configures their own document types. You must query the available types first and only use values from that list. Don't assume standard document types exist universally.

Error #DCO01015 restapi.UnsupportedFileTypeFault indicates the file format isn't accepted. DATEV restricts uploads to specific file types for security and compatibility reasons. The allowed formats vary between DuoNext and legacy systems. Always check the permitted file extensions for your target environment.

Error #DCO01016 restapi.FileSizeFault means your file exceeds the twenty-megabyte limit. Large files create processing and storage burdens. If you're handling oversized documents, you'll need to compress them, split them into multiple uploads, or reconsider your document workflow. DATEV recommends warning users when files exceed 500 KB because even allowed file sizes can slow down system performance.

Error #DCO01253 restapi.DuplicateFileFault signals that a file with identical name and document type already exists in Belege Online. DATEV prevents duplicate uploads to avoid confusion. Your integration should either generate unique filenames, allow users to specify different document types for duplicates, or implement deduplication logic before attempting uploads.

Integration Approaches: Direct vs. Unified APIs

You face a fundamental architectural decision: integrate directly with DATEV or use a unified API provider that abstracts the complexity. Each approach has distinct tradeoffs that affect your development timeline, maintenance burden, and feature coverage.

Direct integration with DATEV gives you complete control over the integration logic. You're not dependent on third-party service availability or pricing changes. You can access all DATEV features without waiting for a middleware provider to expose them. But this control comes with significant complexity. You need deep understanding of CSV and XML format specifications. You're responsible for all batch job management, status monitoring, error handling, and retry logic. Testing requires thorough validation across different client configurations and fiscal year setups. Development cycles stretch longer because you're implementing the entire integration stack yourself. Ongoing maintenance becomes a permanent operational burden as DATEV updates their APIs and format requirements.

Unified API providers like Chift, Maesn, and others offer a RESTful developer experience that feels familiar to modern web developers. These platforms automatically handle batch job creation and management behind the scenes. They provide built-in error handling and retry logic that's been tested across many production deployments. Most importantly, they support multiple accounting platforms beyond DATEV, so your integration code can potentially connect to QuickBooks, Xero, NetSuite, and other systems using the same API patterns. Time to market drops dramatically because you're leveraging pre-built infrastructure. Maintenance overhead shifts to the unified API provider.

The downsides of unified APIs include dependency on third-party service reliability and additional costs beyond DATEV's pricing. Not all DATEV features may be exposed through the unified API wrapper, potentially limiting your integration's capabilities. You're also adding network hops and processing delays compared to direct DATEV communication.

For most development teams, especially those building multi-platform integrations or operating under tight deadlines, unified API providers offer the better path. The productivity gains and reduced maintenance burden usually outweigh the additional costs and potential feature limitations. Direct DATEV integration makes sense primarily for specialized use cases that require features not available through unified APIs, or for large-scale deployments where the volume justifies investing in custom infrastructure.

Practical Implementation Considerations

When you start implementing your DATEV integration, several practical concerns will surface immediately. File naming conventions matter more than you might expect. DATEV recommends UTF-8 encoding with precomposed Unicode characters. Decomposed characters cause problems. Special characters like umlauts must be single code points, not multi-byte sequences. DATEV maintains a whitelist of permitted characters in filenames, and unsupported characters get replaced with underscores automatically. This can create confusion if your system generates filenames with characters outside the whitelist.

Rate limiting and batch processing constraints affect how you design your data synchronization strategy. You cannot stream continuous updates in real-time. Instead, you batch operations and submit them periodically. Determine appropriate batch sizes that balance efficiency against error handling complexity. Larger batches process more efficiently but make error diagnosis harder when something fails.

Error recovery needs thoughtful design because batch processing creates asynchronous failure modes. When a job fails, you need to detect the failure, parse error messages, determine which records caused problems, and decide whether to retry the entire batch or just the failed records. Your integration should implement exponential backoff for transient failures while permanently failing for validation errors that won't resolve through retries.

Testing strategies require access to DATEV sandbox environments. The API specification shows separate endpoints for sandbox testing. Use these extensively before deploying to production. Test with various client configurations, different fiscal year setups, and edge cases in your data. Remember that DATEV may automatically generate subsequent fiscal years under certain conditions, so test your integration's behavior when fiscal year transitions occur.

Final Recommendations

DATEV integration is fundamentally different from typical REST API integration work. The batch-processing architecture, strict format requirements, and certification processes create complexity that shouldn't be underestimated. Before starting development, evaluate your technical resources honestly. Do you have developers with experience in batch processing systems? Can you invest time in understanding DATEV's specific format requirements? Do you need features that unified API providers don't expose?

For most teams, starting with a unified API provider offers the fastest path to a working integration. You can always migrate to direct DATEV integration later if specific requirements demand it. Focus initially on understanding the business workflows, data mapping requirements, and error handling strategies. These concerns remain constant regardless of whether you integrate directly or through middleware.

Document your integration thoroughly, especially the format specifications and validation requirements. Future developers maintaining your integration will need this context. Build comprehensive error logging from day one because diagnosing batch processing failures requires detailed audit trails.

DATEV integration enables powerful accounting automation, but success requires respecting the architectural constraints and compliance requirements that make DATEV the trusted standard for German accounting workflows.

Bank Feeds API Integration: Why You Can’t Afford to Skip This Feature

𝚂𝚊𝚞𝚛𝚊𝚋𝚑 𝚁𝚊𝚒 — Fri, 31 Oct 2025 14:27:10 +0000

Your corporate card product is brilliant. Your business banking app solves real problems. Your expense management platform beats the competition on features and pricing.

But then a prospect asks: "Does this sync with our Xero account?"

And suddenly, you're explaining why users need to export CSVs and manually upload bank statements to their accounting system. The demo goes cold. The deal stalls. Your competitor with the bank feed integration wins the business.

This happens every day to fintech companies that treat bank feeds as a "nice to have" feature. The reality? For finance teams, bank feeds are table stakes. Without them, you're asking users to do work that could be automated via an API integration.

Here's how to fix that.

What Bank Feeds Actually Do (And Why Your Customers Demand Them)

Bank feeds automatically send transaction data from your platform into users' accounting systems, removing the need for CSV uploads and manual entry. The data flows directly from your product into Xero, QuickBooks, or NetSuite as transactions happen.

The primary reason finance teams care about bank feeds is reconciliation. When transactions appear automatically in accounting software, users can match them against invoices, bills, and other entries to close their books faster and with more confidence.

Manual reconciliation involves downloading a CSV or OFX file, reforming the columns, uploading it to their accounting system, and then manually matching each transaction. This takes hours. It creates errors. Finance teams hate it.

Bank feeds eliminate all of that. The transaction happens. Data appears in the accounting system. User clicks to reconcile. Done.

Bank feeds are especially valuable for financial platforms that handle money movement: corporate card providers, business banking apps, expense tools, payout platforms, and accounting automation products. If your product processes transactions on behalf of business customers, those transactions need to flow into their ledger.

While fintechs offer great integrations for accounting software, they traditionally lack access to the resources, APIs, and partnerships required to provide the "bank-like" experience small businesses expect. That's changing, but the expectation exists. Your users want the same experience they get from their bank: automatic feeds, no manual work.

The Use Cases That Actually Drive Revenue

Let's get specific about where bank feeds matter most.

Corporate Cards and Expense Management

Your users swipe corporate cards. Those transactions need to appear in their accounting system the same day, not next week, after someone exports a spreadsheet.

For complete reconciliation, you need two integrations: accounting sync for expenses AND bank feeds for the actual bank transactions. Without both, users still do manual work.

Example: Employee buys office supplies with the company card. Transaction hits your platform. Bank feed sends it to QuickBooks. The finance team opens QuickBooks, sees the transaction, and matches it to the expense report. Approved in 30 seconds instead of 30 minutes.

Business Banking and Neobanks

Fintechs can deliver a bank-like experience by automating the upload of transaction statements to the general ledger for reconciliation. This is what banks do. If you're competing with banks, you need to do it too.

Arc, a fintech company serving startups with treasury management and revenue-based financing, put it clearly: "We offer customers deposit accounts that serve as the core of how they run their business. It's critical for our customers to sync that data to their accounting systems."

Without bank feeds, your business banking app feels incomplete. With them, you're offering the full package.

Bill Pay and AP Automation

Push bill pay transactions to accounting systems for real-time payables reconciliation. When your platform pays a vendor invoice, that payment should appear in the customer's accounting system immediately.

This closes the loop on accounts payable. Your app initiates payment. Bank feed confirms it happened. The accounting system marks the bill as paid. No manual matching required.

Treasury Management

Treasury teams need real-time cash position visibility across multiple bank accounts. Bank feeds provide the data they need to forecast cash flow, manage liquidity, and make funding decisions.

For companies managing cash across subsidiaries or multiple currencies, automated bank feeds make daily treasury operations possible without building custom integrations for every bank account.

Why Direct Integration Is a Nightmare

You might think: "We'll just build a direct integration with Xero. How hard can it be?"

Very hard. Here's why.

Xero's Bank Feeds API is a closed API only available to financial institutions with an established partnership with Xero. You can't just sign up and start using it. You need to:

Apply to become a Xero financial services partner
Wait for approval (no guarantees)
Go through certification process (takes months)
Get your application certified for bank feeds access

That's just for Xero. Now repeat this process for QuickBooks, NetSuite, Sage Intacct, MYOB, and every other accounting platform your customers use.

Each platform has different APIs. Different authentication flows. Different data models. Different certification requirements. Different ongoing maintenance needs.

The math gets ugly fast:

3-6 months per integration
5 major platforms
= 15-30 months of development time
Plus ongoing maintenance when APIs change
Plus customer support for auth issues
Plus compliance and security reviews

And during those 15-30 months, you're not building your core product. You're managing OAuth flows and debugging webhook failures.

Most fintech companies don't have that time. The market moves too fast.

How Apideck Solves the Bank Feed Problem

A unified API aggregates multiple APIs in the same category into a single standardized endpoint with unified authentication and normalized data models. Instead of building 20 separate integrations, you build one.

For bank feeds, this means:

One Integration, Multiple Platforms

Apideck's Accounting API provides a single REST interface to sync data across 20+ accounting platforms. You write your bank feed integration once. It works with Xero, QuickBooks, NetSuite, Sage Intacct, and dozens of other systems.

Your code stays the same. Apideck handles the platform-specific details.

Authentication That Actually Works

Apideck Vault handles OAuth flows and stores credentials securely with enterprise-grade security. Your users connect their accounting system through a white-label interface. They never see your API keys. You never manage their tokens.

The same authentication flow works for every platform. No custom OAuth implementations per provider.

Maintenance You Don't Have to Do

Apideck handles connector updates, API versioning, and provider-specific changes without requiring code changes in your application. When QuickBooks ships a breaking change or Xero updates authentication requirements, Apideck updates the connector. Your code keeps working.

This is huge. Direct integrations break constantly. APIs change. Partners add new requirements. Version deprecations happen with 60 days' notice. With Apideck, that's not your problem anymore.

Normalized Data Models

Apideck normalizes messy, inconsistent APIs into a single structure while still exposing raw downstream information. Every platform uses different field names and data formats. Apideck translates between your standard format and whatever the downstream API expects.

You send the same JSON payload for bank transactions. Apideck converts it to QBXML for QuickBooks Desktop, REST for Xero, or whatever format NetSuite needs. You don't care about implementation details.

Technical Implementation: Xero Bank Feeds with Apideck

Let's get into the actual code. Here's how you implement bank feeds for Xero using Apideck's unified API.

Prerequisites

You still need Xero Bank Feeds API certification. Apideck can't bypass that requirement because it's a partnership between you and Xero. But once you're certified, Apideck handles everything else.

Step 1: Create a Bank Feed Account

The Bank Feed Accounts endpoint in Apideck's Accounting API corresponds to Xero's Feed Connections API and links your platform's accounts to bank or credit card accounts in Xero.

POST to https://unify.apideck.com/accounting/bank-feed-accounts with this payload:

{
  "source_account_id": "corp-card-001",
  "target_account_number": "12345676",
  "target_account_name": "Corporate Card Account",
  "bank_account_type": "bank",
  "currency": "USD"
}

If the bank account already exists in Xero, use target_account_id instead of name and number to link it. If not, provide target_account_name and target_account_number so Xero creates a new account.

The response gives you a bank_feed_account_id:

{
  "data": {
    "id": "55af487b-df2b-425e-9432-ea2db7a77481"
  }
}

Store this ID. You'll need it for every transaction batch you send.

Step 2: Send Bank Transactions

The Bank Feed Statements endpoint lets you send a batch of transactions tied to the bank_feed_account_id created earlier.

POST to https://unify.apideck.com/accounting/bank-feed-statements:

{
  "bank_feed_account_id": "55af487b-df2b-425e-9432-ea2db7a77481",
  "start_date": "2025-05-01T00:00:00.000Z",
  "end_date": "2025-05-15T23:59:00.000Z",
  "start_balance": 100.0,
  "start_balance_credit_or_debit": "credit",
  "end_balance": 142.0,
  "end_balance_credit_or_debit": "credit",
  "transactions": [
    {
      "posted_date": "2025-05-02T01:00:00.000Z",
      "description": "Office Supplies - Staples",
      "amount": 47.23,
      "credit_or_debit": "debit",
      "source_transaction_id": "txn_1019",
      "counterparty": "Staples Inc",
      "reference": "INV-20250502",
      "transaction_type": "payment"
    },
    {
      "posted_date": "2025-05-03T09:30:00.000Z",
      "description": "Client Payment - ACME Corp",
      "amount": 89.23,
      "credit_or_debit": "credit",
      "source_transaction_id": "txn_1020",
      "counterparty": "ACME Corp",
      "reference": "Invoice-445",
      "transaction_type": "payment"
    }
  ]
}

Best practices: Send statements in chronological order, ensure balances align correctly (Xero validates them), and avoid gaps or overlaps in statement periods to prevent rejections.

Step 3: Users Reconcile in Xero

Once the statement is successfully uploaded, transactions appear in Xero under the connected bank account where users reconcile them using Xero's standard process by matching each line to invoices, bills, or other records.

This creates the workflow your finance users expect: your platform sends transactions, Xero handles reconciliation. By automating this flow, you help users maintain accurate books with minimal manual effort.

You can send feeds daily, weekly, or on-demand. Most products send daily updates to keep accounting systems current.

Beyond Xero: Multi-Platform Support

Xero is live and fully supported. But your customers use other accounting systems too, we're actively adding support for more platforms.

SaaS companies typically need multiple accounting integrations to serve diverse customer bases: UK-focused customers use Xero, US SMBs prefer QuickBooks, and enterprise clients require Sage Intacct.

Apideck supports 20+ accounting platforms, including QuickBooks, NetSuite, Sage Intacct, MYOB, Microsoft Dynamics 365 Business Central, FreshBooks, and Exact Online. The same unified API works across all of them.

Different platforms use different formats for bank feed data. While Xero uses its proprietary Bank Feeds API, NetSuite commonly relies on the OFX (Open Financial Exchange) format for importing bank statements. OFX is a standardized format that many banks and financial institutions use to exchange transaction data. If you're building for NetSuite users, understanding OFX formatting becomes important for smooth data imports. Learn more about importing bank statements into NetSuite using OFX format at DocuClipper's guide.

Right now, bank feeds are fully implemented for Xero. Support for additional platforms is expanding. The architecture is already there. The API endpoints are the same. As Apideck adds bank feed support to more connectors, your integration automatically gains access to those platforms.

This matters because you can't predict which accounting system your next big customer will use. Building flexibility into your integration strategy now saves months of work later.

The Bottom Line for Decision Makers

Bank feeds separate products that finance teams actually adopt from products that get evaluated and rejected.

If you're building a fintech product that handles money movement, you need bank feeds. Not eventually. Now.

The choice is:

Build direct integrations to 5-10 accounting platforms over 18-24 months
Use a unified API and ship bank feeds in a few weeks

Development teams can implement accounting integrations in weeks rather than months using unified APIs with standardized webhooks, consistent error handling, and unified documentation that eliminates the complexity of learning multiple provider-specific APIs.

Apideck gives you:

One integration for 20+ accounting platforms
Managed authentication and credential storage
Automatic handling of API changes and updates
Production-ready bank feeds for Xero (with more platforms coming)
Real-time data processing with no batching delays

Next Steps

Ready to add bank feeds to your product?

For Xero Bank Feeds: Start with the detailed technical guide at developers.apideck.com/guides/bank-feeds-xero

For the Full Accounting API: Explore all endpoints and connectors at developers.apideck.com/apis/accounting

To Try It Out: Sign up for a free Apideck account and get 2,500 API calls to test your integration. No credit card required.

To Talk Strategy: Book a demo if you're evaluating unified APIs for your product roadmap. The Apideck team can walk you through your specific use case and integration requirements.

The fintech companies winning deals right now are the ones that solved bank feeds months ago. Stop building one-off integrations. Ship bank feeds this quarter instead of next year.

Your finance team users will thank you.

How to Connect with the HubSpot API

𝚂𝚊𝚞𝚛𝚊𝚋𝚑 𝚁𝚊𝚒 — Thu, 30 Oct 2025 16:43:28 +0000

HubSpot's API looks modern on the surface. REST endpoints, JSON payloads, OAuth 2.0, webhooks. Then you actually build something with it and discover the truth: it's a maze of rate limits, undocumented quirks, and lifecycle stage logic that defies human comprehension.

I've spent the last three years integrating HubSpot for various clients. Here's what the documentation won't tell you and what will save you from the same pain I went through.

The OAuth Dance Nobody Warns You About

HubSpot uses OAuth 2.0, which sounds standard until you realize their implementation has its own special flavor. You need three things before you even start: a developer account (separate from your regular HubSpot account), an app registration, and the patience of a saint.

First, create your app at developers.hubspot.com. You'll get a Client ID and Client Secret. Guard that secret like your life depends on it, because regenerating it will break every existing integration.

Here's the authorization URL you need to build:

const authUrl = `https://app.hubspot.com/oauth/authorize?` +
  `client_id=${CLIENT_ID}&` +
  `redirect_uri=${encodeURIComponent(REDIRECT_URI)}&` +
  `scope=crm.objects.contacts.read%20crm.objects.contacts.write`;

But wait, there's a catch nobody mentions: the redirect URI must match EXACTLY what you registered. Not just the domain, not just the path, but every single character, including trailing slashes. Get it wrong and you'll see a generic error that tells you nothing.

When the user approves, HubSpot redirects back with a code. You have exactly 30 seconds to exchange it for tokens, or it expires:

const tokenResponse = await fetch('https://api.hubapi.com/oauth/v1/token', {
  method: 'POST',
  headers: { 'Content-Type': 'application/x-www-form-urlencoded' },
  body: new URLSearchParams({
    grant_type: 'authorization_code',
    client_id: CLIENT_ID,
    client_secret: CLIENT_SECRET,
    redirect_uri: REDIRECT_URI,
    code: authCode
  })
});

const { access_token, refresh_token } = await tokenResponse.json();

Most access tokens are short-lived. You can check the expires_in parameter when generating an access token to determine its lifetime (in seconds). Practically you have a few minutes before they expire.

Here's the refresh logic you'll need running constantly:

async function refreshAccessToken(refreshToken) {
  const response = await fetch('https://api.hubapi.com/oauth/v1/token', {
    method: 'POST',
    headers: { 'Content-Type': 'application/x-www-form-urlencoded' },
    body: new URLSearchParams({
      grant_type: 'refresh_token',
      client_id: CLIENT_ID,
      client_secret: CLIENT_SECRET,
      refresh_token: refreshToken
    })
  });

  if (!response.ok) {
    // Refresh token is dead, user needs to reauthorize
    throw new Error('Token refresh failed - user must reauthorize');
  }

  return await response.json();
}

You can read more about the refresh access token logic from the HubSpot documentation here.

Rate Limiting: The 429 Error Festival

HubSpot's rate limits are documented, but what they don't tell you is how aggressive they are. You get 100 requests per 10 seconds for public apps. That sounds like a lot until you realize that's shared across ALL your users if you're using a single app registration.

However, you can upgrade the number of calls your app can make, which is based on your account subscription in the account it's installed in. Here's the plan details from the HubSpot Documentation:

[IMAGE: Rate limit table by subscription tier]

Here's what a 429 error looks like when you hit the limit:

{
  "status": "error",
  "message": "You have reached your secondly limit",
  "errorType": "RATE_LIMIT",
  "correlationId": "c033cdaa-2c40-4a64-ae48-b4cec88dad24",
  "policyName": "TEN_SECONDLY_ROLLING"
}

The worst part? HubSpot counts requests that fail against your rate limit. So when you hit the limit and retry immediately, you're making it worse. You need exponential backoff or you'll be stuck in 429 hell forever:

async function makeHubSpotRequest(url, options, retryCount = 0) {
  const response = await fetch(url, options);

  if (response.status === 429) {
    if (retryCount >= 5) {
      throw new Error('Max retries exceeded');
    }

    // Exponential backoff: 1s, 2s, 4s, 8s, 16s
    const delay = Math.pow(2, retryCount) * 1000;
    console.log(`Rate limited. Waiting ${delay}ms before retry...`);

    await new Promise(resolve => setTimeout(resolve, delay));
    return makeHubSpotRequest(url, options, retryCount + 1);
  }

  if (!response.ok) {
    throw new Error(`HubSpot API error: ${response.status}`);
  }

  return response.json();
}

But here's the real kicker: if you're using Make.com, Zapier, or any integration platform, you're sharing rate limits with every other customer using their HubSpot connector. I've seen perfectly reasonable workflows fail at 2 AM because someone else's integration went haywire. The only solution is to create your own OAuth app and use their "advanced" connection option.

The Lifecycle Stage Nightmare

HubSpot's lifecycle stages are supposed to track where contacts are in your sales process. In reality, they're a one-way street designed by someone who's never had to fix bad data.

Lifecycle stages can only move forward by default. Lead to Customer? Fine. Customer back to Lead because they canceled? Nope. You have to clear the field first, then set the new value in a separate API call:

// This won't work - lifecycle stage can't go backwards
await updateContact(contactId, { lifecyclestage: 'lead' }); // Fails silently

// This is what you actually need
await updateContact(contactId, { lifecyclestage: '' }); // Clear it first
await updateContact(contactId, { lifecyclestage: 'lead' }); // Now set it

async function updateContact(contactId, properties) {
  return makeHubSpotRequest(
    `https://api.hubapi.com/crm/v3/objects/contacts/${contactId}`,
    {
      method: 'PATCH',
      headers: {
        'Authorization': `Bearer ${accessToken}`,
        'Content-Type': 'application/json'
      },
      body: JSON.stringify({ properties })
    }
  );
}

That's two API calls for one field update, doubling your rate limit usage. And it gets worse: the batch API doesn't guarantee order, so you can't clear and set in the same batch request. Every backwards lifecycle stage movement costs you two separate API calls.

Oh, and those "Became a [stage] date" properties? They're being deprecated. HubSpot announced this in 2024, but half of its documentation still references them. You now need to use their "calculated properties," which have their own special quirks and can't be set via API at all.

Custom Properties: The False Promise

HubSpot lets you create custom properties for anything. Sounds great until you realize that enumeration properties (dropdowns, checkboxes) have their own internal IDs that aren't the same as the labels you see in the UI.

You think you're setting a property to "Enterprise Customer," but HubSpot wants "enterprise_customer_7821" or something equally ridiculous. To find the internal values, you need to query the properties endpoint first:

const propertyResponse = await makeHubSpotRequest(
  'https://api.hubapi.com/crm/v3/properties/contacts/industry',
  {
    headers: { 'Authorization': `Bearer ${accessToken}` }
  }
);

// Returns something like:
// {
//   "options": [
//     { "label": "Enterprise Customer", "value": "enterprise_customer_7821" },
//     { "label": "SMB Customer", "value": "smb_customer_9183" }
//   ]
// }

And don't even think about changing these values later. Every integration, workflow, and report using that property will break. I learned this when a client wanted to rename "Hot Lead" to "Qualified Lead" and it took three days to fix all the broken automations.

Webhooks: Death by a Thousand Subscriptions

HubSpot webhooks seem straightforward: subscribe to events, receive notifications. What they don't tell you is that webhooks are tied to your app, not individual accounts. Every customer using your app shares the same webhook URL.

Setting up webhooks requires a verified domain and HTTPS endpoint that can handle HubSpot's validation:

app.post('/webhook', (req, res) => {
  // HubSpot sends validation on setup
  if (req.headers['x-hubspot-signature']) {
    const signature = req.headers['x-hubspot-signature'];
    const sourceString = req.method + req.url + req.rawBody;
    const hash = crypto.createHash('sha256')
      .update(CLIENT_SECRET + sourceString)
      .digest('hex');

    if (hash !== signature) {
      return res.status(401).send('Invalid signature');
    }
  }

  // Process webhook events
  req.body.forEach(event => {
    console.log(`Event: ${event.eventType} for object ${event.objectId}`);
    // But which customer is this for? Good luck figuring that out
  });

  res.status(200).send();
});

The webhook payload doesn't include which account it's from. You get an object ID and have to make another API call (counting against your rate limit) to figure out whose data changed. With 100 customers, that's 100 extra API calls per webhook event.

The Undocumented Reality

Here's what HubSpot won't tell you but you need to know:

The API versions are complex. There's v1, v2, and v3 running simultaneously. Some endpoints only exist in v1 (looking at you, Engagements API), some features are v3 only, and they're deprecating v1 "soon" (they've been saying this for three years).

Private apps are not the same as OAuth apps. Private apps use API keys and are simpler but can't be distributed. OAuth apps can be shared but require the whole token dance. Choose wrong and you'll be rebuilding your integration from scratch.

The search API is basically useless. It has a different rate limit (4 requests per second), can't search all properties, and sometimes returns stale data. One client had contacts appearing in search results three hours after deletion. The only reliable way to find data is to pull everything and filter locally.

Error messages lie. You'll get "Contact already exists" when the real problem is a malformed email. You'll get "Invalid property value" when the property doesn't exist. Always log the full request and response because the error message alone won't help you debug.

Associations are their own special hell. Want to link a contact to a company? That's a separate API call. Want to see all contacts for a company? Another call. Want to update the association? You can't, you have to delete and recreate it. Each operation counts against your rate limit.

Making This Bearable with TypeScript

If you're building anything serious, use TypeScript. HubSpot's API responses are inconsistent and TypeScript will save you from runtime explosions:

interface HubSpotContact {
  id: string;
  properties: {
    email?: string;
    firstname?: string;
    lastname?: string;
    lifecyclestage?: string;
    [key: string]: string | undefined;
  };
  createdAt: string;
  updatedAt: string;
}

interface HubSpotError {
  status: 'error';
  message: string;
  correlationId: string;
  errorType?: 'RATE_LIMIT' | 'VALIDATION_ERROR' | 'NOT_FOUND';
}

class HubSpotClient {
  constructor(private accessToken: string) {}

  async getContact(id: string): Promise<HubSpotContact> {
    const response = await this.request<HubSpotContact>(
      `https://api.hubapi.com/crm/v3/objects/contacts/${id}`
    );
    return response;
  }

  private async request<T>(url: string, options: RequestInit = {}): Promise<T> {
    const response = await fetch(url, {
      ...options,
      headers: {
        'Authorization': `Bearer ${this.accessToken}`,
        'Content-Type': 'application/json',
        ...options.headers
      }
    });

    if (!response.ok) {
      const error = await response.json() as HubSpotError;
      throw new Error(`HubSpot API Error: ${error.message}`);
    }

    return response.json() as Promise<T>;
  }
}

The Apideck Escape Hatch

Look, I've built enough HubSpot integrations to know when to quit. If you need HubSpot plus other CRMs (Salesforce, Pipedrive, etc.), stop building separate integrations and use a unified API.

Apideck's unified CRM API handles HubSpot's quirks so you don't have to. One integration instead of five, OAuth complexity handled, rate limiting managed across their infrastructure, and lifecycle stage nonsense abstracted away. Your 6-week HubSpot integration can be done easily within two weeks of actual coding. And not only this, you can configure other CRMs as well.

Apideck's CRM Unified API

// Direct HubSpot API: OAuth dance, token refresh, rate limiting, lifecycle stage hell
// Apideck: Just this

import { Apideck } from '@apideck/node';

const apideck = new Apideck({
  apiKey: process.env.APIDECK_API_KEY,
  appId: process.env.APIDECK_APP_ID,
  consumerId: 'customer-123' // Your customer's ID
});

// Create a contact in HubSpot (or any CRM they've connected)
async function createContact() {
  try {
    const contact = await apideck.crm.contactsAdd({
      serviceId: 'hubspot', // Or 'salesforce', 'pipedrive', etc.
      contact: {
        firstName: 'John',
        lastName: 'Doe',
        email: 'john@example.com',
        phoneNumbers: [{ number: '+1-555-1234', type: 'work' }],
        // Lifecycle stage just works - no backwards movement BS
        lifecycleStage: 'lead',
        customFields: [
          { id: 'industry', value: 'Technology' }
        ]
      }
    });

    console.log('Contact created:', contact.data.id);
  } catch (error) {
    // Actual useful error messages
    console.error('Error:', error.message);
  }
}

// Get all contacts with pagination handled automatically
async function getAllContacts() {
  const contacts = await apideck.crm.contactsAll({
    serviceId: 'hubspot',
    filter: {
      email: 'john@example.com'
    }
  });

  // No manual pagination, no rate limit management
  for await (const contact of contacts) {
    console.log(contact.name, contact.email);
  }
}

// The same code works for ANY CRM - just change serviceId
async function syncToMultipleCRMs(contactData) {
  const crms = ['hubspot', 'salesforce', 'pipedrive'];

  for (const crm of crms) {
    await apideck.crm.contactsAdd({
      serviceId: crm,
      contact: contactData
    });
  }
  // That's it. No OAuth per platform, no different APIs, no rate limit juggling
}

Compare that to the 200 lines of OAuth handling, rate limit retry logic, and lifecycle stage workarounds you need for direct HubSpot integration. One API, consistent data models, errors that actually make sense.

Tangible benefits that matter:

Unified API for all CRM platforms
One integration for HubSpot, Salesforce, Pipedrive, and 50+ others
Field mapping that actually works - Including HubSpot's lifecycle stages and custom properties
No more OAuth gymnastics - They handle token refresh, expiration, all of it

Ship Something That Works

HubSpot's API is powerful but exhausting. You'll spend more time handling edge cases than building features. Every integration starts simple and ends with dozens of workarounds for HubSpot's peculiarities.

My advice? Start with the smallest possible integration. Get OAuth working. Make one API call successfully. Handle rate limits properly. Only then add more complexity. And when you inevitably hit the wall where you're spending more time fighting HubSpot than building your product, consider whether a unified API makes more sense.

The perfect HubSpot integration doesn't exist. Ship something that works, iterate based on which errors your customers actually hit, and keep a bottle of whiskey handy for when HubSpot changes something without warning.

Because they will, they always do.