Xero API Pricing Changes 2026: Costs, Tiers, and How to Cut Egress

Xero is now charging for API access. On March 2, 2026, Xero retired its 15% App Store revenue-share model and replaced it with a five-tier pricing structure based on two metrics: the number of connected Xero organizations (tenants) and monthly data egress volume. If you're a B2B SaaS company that integrates with Xero, this directly impacts your COGS.

For engineering leaders and product managers, the headline isn't just the new monthly subscription fees. The real threat to your unit economics is the introduction of aggressive data egress limits. Xero now charges $2.40 AUD per extra gigabyte of data downloaded from its APIs. If your application relies on a sync-based integration architecture—constantly polling Xero to mirror data into your own database—these changes will wreck your integration margins.

The "all you can eat Xero data buffet" is officially over. This guide breaks down the new pricing tiers, calculates the hidden costs of data egress, and explains how to architect your Xero integration to avoid massive overage bills.

The End of Free Xero API Access: What Changed on March 2, 2026?

Historically, Xero monetized its developer platform by taking a 15% revenue share from applications sold through the Xero App Store. If you acquired customers outside their marketplace, or if you didn't charge specifically for the Xero integration, your API access was effectively free—constrained only by standard rate limits.

That model ended on March 2, 2026. Xero announced that from 2 March 2026, its current "revenue share" model with third-party apps, where Xero took 15% of monthly revenue on sales made via the Xero App Store, will be retired. The announcement landed on December 4, 2025, and the accounting ecosystem reacted harshly. For many of Xero's third-party partners, often smaller vendors attracted by the company's long-standing commitment to an open ecosystem, the move feels like a rug pull that threatens their survival. Developers who previously paid nothing (or very little) are now facing bills that could reach tens of thousands per year, with one reporting that their annual cost would jump from nearly zero to over $17,000 overnight.

Why is Xero doing this? The strategic logic is straightforward. Xero is used in over 180 countries by more than 4.6 million subscribers and integrates with over 1000 third-party apps. That ecosystem generates enormous API traffic. SaaS companies have increasingly adopted unified APIs and third-party integration platforms that use "sync" or "cache" architectures. These platforms aggressively poll Xero's endpoints every few hours to download full datasets—invoices, contacts, journal entries—to keep an intermediate database updated. This places a massive compute and bandwidth burden on Xero's infrastructure, often for data that the end-user never actually queries.

By monetizing data egress directly, Xero creates a new revenue stream tied to platform usage rather than App Store sales—while also establishing a financial disincentive against excessive data extraction. Industry publications like Accountants Daily have already noted that these operational costs will inevitably be passed down to end-users if developers don't rethink their architectures.

There is no grandfathering of the previous pricing model. App migration will begin starting mid March, 2026. Existing apps will receive notice (at least) 30 days prior to their migration with details of their new tier and any required actions. Mandatory deadline: Ensure all of your customers are transitioned by 1 July, 2026.

Breakdown of the New Xero API Pricing Tiers

Here's the full pricing table, sourced from Xero's official developer pricing page:

*Starter tier has unlimited egress but is capped at 5 connections, making it viable only for MVPs and testing.

Data egress is defined as the total volume of data transferred out of Xero's systems via API GET responses. Data ingress (uploads to Xero) remains unlimited and free at all tiers—only data pulled from Xero counts against your allowance. All GET requests count toward your allowance, with one exception: the Organisation endpoint is excluded, recognizing its common use as a connectivity check.

A few important details about this structure:

• Pricing is measured at the app level. Connection count and API data consumption via the Xero API is measured and priced at the app level. Apps cannot share connection counts or API volume used, even if they are from the same developer. If you operate multiple Xero apps, each gets its own bill.
• Egress resets monthly. API data egress volume via the Xero APIs is based on gigabytes used and is a monthly allotment. These reset on the first of the calendar month (using UTC timezone).
• You can downgrade, but only twice per year. If they wish, users can request to downgrade two times per year to account for seasonality.

For US-based developers, here's the USD math: For US-based developers, the Advanced tier translates to approximately $895 USD/month or $10,740 USD annually. The Core tier is roughly $22 USD/month, and Plus is roughly $155 USD/month. The $2.40 AUD overage fee works out to about $1.50 USD per extra gigabyte.

Premium Endpoints Locked Behind the Advanced Tier

The Journals endpoint, Xero Practice Manager API, and Bulk Connections require a security assessment (initial and annual) and use case approval, and they are only available starting at the Advanced tier.

This is significant. The Journals endpoint is what you use to retrieve the complete double-entry journal for an organization—every transaction, every matching entry. If you're building a reconciliation tool, a financial reporting product, or any app that needs a complete view of the books, you need Journals. And that means you need the Advanced tier.

For developers building reconciliation tools, reporting solutions, or apps serving accounting firms, this creates a ~$10,740 USD annual minimum before writing a single line of business logic.

Bulk Connections—the feature that lets a single user (typically an accountant) authorize your app for dozens or hundreds of client organizations in one OAuth flow—is also locked to Advanced. If you're selling to accounting firms, you're paying $895/month minimum. No negotiation.

The AI Data Restriction You Can't Ignore

The primary update prohibits the use of data obtained through Xero's APIs to train or contribute to the creation of any AI or machine learning model. This is to bolster user trust and data security.

This ban is absolute. If you're building an AI-powered finance product and you planned to use Xero transaction data to fine-tune models, that path is now contractually blocked. The restriction doesn't just cover training—it covers "contributing to the creation of" any AI/ML model, which is broad enough to include building embeddings, generating synthetic datasets, or feeding data into RAG pipelines that inform model outputs during training. Violating this clause results in immediate API key revocation.

Using Xero data for live inference—say, querying an invoice amount to answer a user question in real time—appears to be permitted. But you cannot store that data in a vector database for generalized model training. The distinction is between retrieval-augmented generation for a specific user's prompt and building a training corpus.

The industry reaction has been mixed. One expert noted that the AI training ban might do the exact opposite of what Xero intends. At the moment, a lot of new apps don't build a general ledger (GL) and just use Xero. They've now created the conditions where AI-native tools are driven to build their own GLs. By locking down financial data, Xero may be pushing the next generation of accounting tools to stop treating Xero as the system of record entirely.

Review Xero's updated Developer Platform Terms carefully with your legal team before shipping anything AI-adjacent.

The Hidden Trap: Data Egress and Sync-Based Architectures

Here's where the new pricing gets dangerous for B2B SaaS companies that rely on integration middleware.

Many integration platforms—unified APIs, embedded iPaaS tools, and homegrown sync engines—operate on a sync-based architecture. They periodically poll the Xero API, download entire datasets (all invoices, all contacts, all accounts), store them in an intermediate database, and serve data from that cache. Your application then reads from their database, not Xero's.

Under the old model, this was annoying but free. Under the new model, every byte of that polling counts as egress.

Let's run the numbers. Say your integration polls Xero every 15 minutes for 200 connected organizations. Each poll fetches invoices, contacts, and accounts—about 2 MB of JSON per organization per sync cycle:

• 200 orgs × 2 MB × 96 syncs/day × 30 days = ~1,152 GB/month

At the Core tier, you get 10 GB included. The remaining 1,142 GB at $2.40 AUD/GB is $2,740 AUD ($1,713 USD) in overage fees alone—on top of your tier fee. Even at the Plus tier (50 GB included), you're still looking at $2,644 AUD in overages.

The advice from sync-based providers has been telling. Codat explicitly told its customers: "Please review your datasets' sync frequency in the Codat portal." When your integration provider tells you to stop syncing data, their core architectural model is fundamentally broken.

The fundamental problem isn't the sync frequency—it's the architecture. Sync-based systems download data speculatively. They pull everything in case you might need it. When egress is free, that's just wasteful. When egress costs $2.40/GB, it's a line item on your P&L.

This is why we are seeing hidden costs in unified API pricing models compound drastically. The Xero egress bill your middleware generates lands on your developer account—not the middleware vendor's. Their pricing model is disconnected from the API cost they impose on your behalf.

How to Architect Your Xero Integration to Minimize Egress

Whether you're building a direct integration or evaluating middleware, here are the architectural patterns that keep egress under control.

1. Use Xero Webhooks for Event-Driven Updates

Instead of polling Xero every hour to see if a new invoice was created, rely on webhooks. Xero supports webhooks for Contacts, Invoices, and (in beta) Credit Notes, allowing your application to react immediately to changes in Xero data without the need for constant polling.

A critical detail: Xero webhooks deliver thin payloads—they send you the resource ID and event type, not the full resource. You still need to make a GET request to fetch the actual data. But that's a single, targeted request for one record—not a bulk download of every invoice in the organization.

sequenceDiagram
    participant Xero
    participant Your App
    Xero->>Your App: Webhook: Invoice INV-123 updated
    Your App->>Xero: GET /api.xro/2.0/Invoices/INV-123
    Xero-->>Your App: Single invoice JSON (~2KB)
    Note over Your App: Process only what changed<br>Egress: ~2KB vs ~2MB for full sync

The egress difference is massive. A webhook-driven architecture that fetches only changed records might use 0.5 GB/month where a polling architecture uses 500 GB/month for the same set of organizations.

Building this properly requires robust infrastructure: verify the signature of incoming payloads, handle exponential backoff when workers are busy, and maintain idempotency to ensure you don't process the same webhook twice. For more, see our guide on handling webhooks and real-time data sync from legacy APIs.

2. Use If-Modified-Since for Delta Sync

When you need to poll—not all entity types support webhooks—Xero's Accounting API supports the If-Modified-Since header on most GET endpoints. This returns only records changed since the timestamp you provide. This retrieves only changed records, reducing both calls and egress dramatically.

curl -H "Authorization: Bearer $TOKEN" \
     -H "If-Modified-Since: 2026-03-29T12:00:00Z" \
     https://api.xero.com/api.xro/2.0/Invoices

If nothing changed, you get a 304 with zero body. If five invoices changed, you get five invoices—not five thousand.

3. Adopt a Real-Time Proxy Architecture

If you need to display a list of accounts to a user in your UI, don't sync the entire chart of accounts to your database overnight. Fetch it in real time when the user opens the page.

A real-time proxy architecture translates your application's request into Xero's native format on the fly, forwards the request to Xero, and translates the response back—without ever saving the payload to disk. Because you only request data when a user actively triggers an action, your egress volume drops by orders of magnitude compared to background polling.

4. Implement Strict Filtering and Pagination

Xero's API supports filtering via the where parameter. Never request a full list of invoices and filter them in your application code. Always push the filtering logic down to the API request.

If you only need unpaid invoices from the last 30 days, append the specific OData filter to your request. By combining strict filtering with cursor-based pagination, you ensure that every byte of data you download—and pay for—is actually used by your application.

5. Cache Slowly-Changing Reference Data

Chart of Accounts, Tax Rates, Currencies, and Tracking Categories rarely change. Cache them with a TTL of 4–12 hours and invalidate via webhooks. Contact information can reasonably cache for 15–30 minutes. There's no reason to re-fetch your Chart of Accounts every sync cycle.

6. Prune Inactive Connections

Your tier is determined by your connection count. The new "Manage Your Connections" feature lets you disconnect inactive connections to potentially qualify for a lower tier. If you have 60 connections but 15 of them haven't been used in six months, disconnecting those 15 drops you from Plus ($245 AUD/month) to Core ($35 AUD/month). Audit your connections before migration.

7. Front-Load Initial Syncs, Then Go Incremental

The single biggest egress offender is the initial sync—the moment you connect a new Xero organization and download its entire history. Use Xero's Rapid Sync feature (available to certified Plus+ apps), which lifts rate limits for the first 30 minutes of a new connection, to front-load this initial pull efficiently.

After the initial sync, never fetch full collections again. Use If-Modified-Since, webhooks, or pagination with narrow date filters to pull only what's new.

Why Real-Time Proxy Architectures Beat Sync-Based Polling

The Xero pricing change exposes a structural weakness in sync-based integration platforms: they treat data egress as a background cost that someone else pays for. This compounds the frustration for engineering teams already tired of being punished for growth by per-connection API pricing.

A real-time proxy architecture works differently. Instead of pre-fetching and caching entire databases, it translates your API request into a Xero API call on the fly, returns the response, and discards the data. You only consume egress when your application actually needs data—not on a schedule.

flowchart LR
    subgraph Sync Architecture
        direction TB
        S1["Scheduler polls Xero<br>every 15 min"] --> S2["Downloads ALL<br>invoices, contacts, etc."] --> S3["Stores in<br>intermediate DB"] --> S4["Your app reads<br>from cache"]
    end
    subgraph Proxy Architecture
        direction TB
        P1["Your app requests<br>Invoice #1234"] --> P2["Proxy translates to<br>Xero GET request"] --> P3["Returns data<br>directly to your app"]
    end

    style S2 fill:#ff6b6b,color:#fff
    style P2 fill:#51cf66,color:#fff

The egress math tells the whole story:

For a detailed comparison of these two approaches, our article on tradeoffs between real-time and cached unified APIs breaks down latency, consistency, and cost considerations.

How Truto Eliminates Egress Waste by Design

The architectural shift required to minimize Xero API costs is significant. Building a real-time proxy layer, managing OAuth token lifecycles, and normalizing webhooks across multiple accounting platforms takes months of engineering time.

This is where Truto's architecture becomes directly relevant to the 2026 pricing changes. Unlike legacy unified APIs that cache your data and drive up your egress bills, Truto operates as a real-time proxy. When you use Truto as your unified accounting API, you're protected by design.

Zero Data Retention. Truto does not store your customers' third-party data. There is no intermediate database. When you make a request to the unified API, the engine uses declarative mapping configurations to translate your request into Xero's native format, fetches exactly what you asked for, translates the response, and passes it directly to your application. Because there is no background polling, your Xero egress is limited strictly to active user usage.

Unified Webhooks. Truto normalizes incoming webhooks from Xero into a standardized event schema. The platform ingests the provider webhook, verifies security signatures, maps the event to a unified format, and delivers it to your endpoints. You get event-driven architecture without writing integration-specific webhook handlers—and the same event schema works whether the source is Xero, QuickBooks Online, or NetSuite.

Intelligent Token Management. As noted in our guide to integrating with the Xero API, Xero requires OAuth 2.0 authentication with tokens that expire every 30 minutes. Truto handles the entire lifecycle, automatically refreshing OAuth tokens shortly before they expire using standard exponential backoff and circuit breaker patterns. Your real-time requests never fail due to stale credentials.

Declarative Pagination. Truto's unified API normalizes pagination across providers. You request a page size, and the platform handles the underlying Xero pagination logic—ensuring you never over-fetch data by accident.

Sync-based platforms will push you into Xero's expensive Advanced tier purely through background polling waste. A real-time proxy architecture keeps your egress footprint tiny, letting you support hundreds of customers while remaining in the cost-effective Core or Plus tiers.

What This Means for Your Integration Strategy

Xero's pricing change isn't an isolated event. The move is similar to one introduced by accounting software rival Intuit QuickBooks in November 2025 (a shift we break down in our QuickBooks Online API integration guide). The trend is clear: accounting platforms are monetizing API access as a standalone revenue stream. If you're building integrations across multiple accounting providers, your architecture needs to be egress-aware by default.

Here's a checklist for engineering and product leaders:

• Audit your current Xero egress. Log in to the Xero developer portal and check your usage tab. Know your baseline before migration.
• Map your integration to a tier. Count active connections and estimate monthly egress. If you're above 10 GB/month, you need Plus or higher.
• Eliminate speculative polling. Every GET request that fetches data "just in case" is now costing you money. Be surgical.
• Adopt webhooks where available. Xero supports them for Contacts and Invoices. Use them.
• Evaluate your middleware's architecture. If your integration provider syncs data on a schedule, ask them exactly how much Xero egress that generates per connected account per month. If they can't answer, that's a red flag.
• Plan for July 1, 2026. You will need to migrate your customers off of XASS by 1 July, 2026. If you were using Xero App Store Subscriptions, you need your own billing flow before that deadline.

The companies that treat this pricing change as an architecture problem—not just a budgeting problem—will come out ahead. Under the new model, developers will incur significant costs, which could become one of their largest expenses. The ones that keep polling every 15 minutes and eating the overage fees will watch Xero API costs devour their integration margins.

Don't let third-party API pricing changes break your unit economics. Architect for efficiency from day one.