How long do Xero access tokens last?

Access tokens expire after 30 minutes. Refresh tokens expire after 60 days of inactivity. Long-running syncs must refresh tokens mid-process, which makes proactive token refresh the single most important reliability detail in a Xero integration. Refresh around the 25-minute mark rather than waiting for a 401, which avoids a race that drops the connection.

Does Xero support webhooks?

Yes, but only for contacts, invoices, credit notes, and subscriptions, on create and update. There are no webhooks for bank transactions, payments, journal entries, accounts, or tax rates, so those require polling with the If-Modified-Since header. Webhook endpoints must pass an Intent to Receive validation and respond within 5 seconds, or Xero disables them.

Can I connect Power BI or Tableau to Xero?

Yes, through the API or third-party connectors. For anything beyond a small dataset, sync Xero data into a data warehouse first and connect your BI tool to that, which controls both query performance and egress cost under the new pricing.

Can I get an aged receivables report for all contacts at once?

Not directly. Xero's aged-report endpoints return one contact at a time. For an all-contacts aging view, reconstruct it from invoice due dates and payment records, which uses far fewer API calls and keeps you inside the rate limits. Calling the dedicated endpoint once per contact across hundreds of customers collides with both the rate limits and the egress meter.

Does the Xero API have a cash flow statement?

No. There is no cash flow statement endpoint. You derive it from bank transactions and journal data, even though Xero shows a cash flow report inside its own web interface. This surprises teams who assume any report visible in the Xero UI is also available over the API.

Xero API Integration in 2026: Pricing, Scopes, Dashboards

Q: What changed in the Xero API in 2026?

Two major things. As of March 2, 2026, Xero replaced its free revenue-share model with tiered, usage-based pricing that charges for data egress. And for apps created after that date, Xero replaced its two broad OAuth scopes with ten granular ones, with existing apps required to migrate by September 2027.

Q: How much does the Xero API cost in 2026?

It depends on tier and data egress. There is a free Starter tier capped at 5 connections, paid Core and Plus tiers with 10 GB and 50 GB monthly egress allowances, an Advanced tier at $895 per month with 250 GB, and a negotiated Enterprise tier. Overages on egress are billed on top of the monthly fee.

Q: What are the Xero API rate limits?

Per organization per app: 5 concurrent calls, 60 calls per minute, and 5,000 calls per day (1,000 on the free Starter tier), with the daily limit resetting at midnight UTC. There is also an app-wide ceiling of 10,000 calls per minute across all connected organizations.

Xero API integration diagram showing OAuth scopes, egress-based pricing tiers, webhooks, and a reporting dashboard layer

If you are planning a Xero integration in 2026, the most important thing to know is that the rules changed in March. Xero spent more than a decade as the platform with a famously open, free API, the one that helped it build an ecosystem of over 500 apps serving 4.6 million subscribers. That era is over. As of March 2, 2026, Xero charges developers based on how much data they pull, and it rebuilt its permission model from the ground up. Any guide written before late 2025, and most of the integrations built on them, are now working against rules that no longer apply.

I have built integrations on top of several accounting platforms, and the architectural decisions rhyme from one to the next: authentication, sync strategy, and a reporting layer on top. The same patterns I described in my Silverfin API integration guide apply to Xero too. But Xero in 2026 has a specific set of constraints that change how you should scope a project, and getting them wrong is now measured in money, not just engineering time, because the meter is running on every record you extract.

What Changed in the Xero API in 2026

Two things changed, and both matter before you write a line of code.

Xero introduced tiered, usage-based pricing. On December 4, 2025, Xero announced it was retiring its old revenue-share model, and on March 2, 2026 the new model took effect. Instead of free, near-unlimited API access, developers now pay a flat monthly fee across five tiers, and crucially, each tier includes an allowance of data egress, meaning the volume of data your app pulls out of Xero, measured in gigabytes per month. It is, in effect, the end of the “all-you-can-eat Xero data buffet.” There is no grandfathering of the old model, and every existing app must be transitioned by July 1, 2026.

Xero rebuilt its OAuth permission scopes. For any app created after March 2, 2026, Xero replaced its two broad OAuth 2.0 scopes with ten granular ones. Existing apps have until September 2027 to migrate. In plain terms, your integration now has to ask for narrower, more specific permissions, which is better for security but means more careful scoping up front and a migration deadline on the calendar for anything already built.

The takeaway for a business decision-maker: a Xero integration is no longer a free technical exercise. It now has a direct, ongoing cost that scales with how much data you move, which means the smart architectural choices (caching, syncing only what changed, avoiding needless full re-pulls) are now cost-control choices too. The team that designs for low egress pays less, every single month.

How Much Does the Xero API Cost in 2026?

Xero API pricing now runs across five tiers, from a free Starter tier (up to 5 connections, 1,000 daily calls per org) to a negotiated Enterprise tier. The two cost drivers are the number of connected Xero organizations (tenants) and monthly data egress in gigabytes, and at every paid tier egress overages are billed on top of the flat monthly fee.

Tier	Monthly fee	Connections	Included egress	Daily rate limit
Starter	$0	Up to 5	Unlimited (but capped at 5 connections)	1,000 calls per org
Core	Paid	Higher	10 GB per month	5,000 calls per org
Plus	Paid	Higher	50 GB per month	5,000 calls per org
Advanced	$895	Up to 10,000	250 GB per month	5,000 calls per org
Enterprise	Negotiated	No limit	Negotiated	5,000 calls per org

A few things worth pulling out of that table. The Starter tier is free but capped at five connections, which makes it viable for building and testing a proof of concept but not for serving real customers at scale. Every tier from Core upward meters egress, and overages are billed on top of the monthly fee. All tiers above Starter share the same per-organization daily rate limit of 5,000 calls, so the differentiator between paid tiers is connection count and how much data you are allowed to pull, not how fast.

The business implication: before you commit to Xero, estimate your egress. A read-heavy use case (analytics, dashboards, reporting that re-pulls data frequently) can burn through a gigabyte allowance faster than you would expect, and that is exactly the kind of integration most businesses want. Designing to minimize egress is now part of the project scope, not an afterthought.

What Are the Xero API Rate Limits, Token, and Webhook Limits?

Xero imposes four technical constraints that dictate how any integration has to be built: 30-minute access tokens, layered rate limits, webhooks for only four event types, and a strict webhook delivery contract. None of them are dealbreakers, but all of them are cheaper to know about before you start.

Access tokens expire every 30 minutes. This is short. Any sync that runs longer than half an hour has to refresh its access token mid-process, and if that refresh fails, the connection drops and the customer has to manually re-authorize. Refresh tokens themselves expire after 60 days of inactivity. The practical consequence is that token management is not a “set it and forget it” detail in a Xero integration; it is the single most common cause of “the integration stopped working” support tickets, and it needs to be built carefully with proactive refresh.

Rate limits are strict and layered. Xero enforces several limits at once, per organization per app: a maximum of 5 calls running at the same time (concurrent), 60 calls per minute, and 5,000 calls per day, with the daily counter resetting at midnight UTC. There is also an app-wide ceiling of 10,000 calls per minute across all your connected organizations. Hit any of these and you get a 429 Too Many Requests response. In practice, the 60-calls-per-minute limit is the one that trips teams up most often, not the daily cap. Every response includes headers telling you how much budget you have left against each limit, so a well-built integration tracks those and backs off gracefully.

Webhooks exist, but only for a few events. Xero supports webhooks so your system can react the moment something changes, but only for a limited set: contacts, invoices, credit notes, and subscriptions, each on create and update. There is no webhook for bank transactions, payments, journal entries, accounts, or tax rates. For everything not covered, you fall back to polling with the If-Modified-Since header to pull only what changed. This creates a split architecture where some data is event-driven and the rest is poll-based, which is worth understanding when you scope timelines.

Webhook delivery has a tight contract. If you use Xero webhooks, your endpoint must validate every incoming request using an HMAC-SHA256 signature (Xero sends a signature header you check against your signing key), respond within 5 seconds over HTTPS, and pass an initial “Intent to Receive” validation before Xero will send real events. Miss the signature check or the 5-second window and deliveries fail. If they keep failing, Xero retries with decreasing frequency for 24 hours, then disables the webhook until you manually re-enable it. Events that occur while it is down are saved for up to 31 days and replayed once it is healthy again.

What Reporting Limitations Does the Xero API Have?

The Xero API has five reporting limitations that consistently surprise teams building dashboards: customers and suppliers share one model with no API-level filter, aged-receivables endpoints return one contact at a time, there is no cash flow statement endpoint, tracking-category breakdowns are inconsistent, and record updates require sending the whole object.

Customers and suppliers live in one table. Xero does not separate customers and suppliers. They share a single Contacts model, distinguished only by isCustomer and isSupplier flags, and a single contact can be both. There is also no way to filter invoices to just customers at the API level, so a common pattern is to pull the list of customer contacts first, then filter invoices against that list in your own code. Get this wrong and your “customer revenue” report silently includes supplier transactions.

Aged receivables and payables come one contact at a time. This is the constraint that catches teams off guard most often. If you want an aged AR or AP report (the breakdown of who owes you what, and how overdue it is), Xero’s API does not let you pull it for all contacts in one call. The dedicated aged-report endpoints return data for a single contact at a time. For a business with hundreds of customers, naively building an aging dashboard means hundreds of API calls, which collides directly with the rate limits and the new egress meter. The practical workaround is to reconstruct aging yourself from invoice due dates and payment records, which is far more call-efficient but is real work to get right.

There is no cash flow statement endpoint. Xero’s API does not expose a cash flow statement. If your dashboard needs one, you derive it from bank transactions and journal data. This catches teams who assume that because Xero shows a report in its own interface, the same report is available over the API. Many are; this one is not.

Reports do not always break down by tracking category. Xero uses tracking categories (department, project, location) to segment financial data, but several report endpoints, including the trial balance, have historically had limited or inconsistent support for returning data split by those categories. If your reporting depends on per-department or per-project breakdowns, validate that the specific report endpoint you need actually returns them before you promise it to anyone.

You must send the whole object on updates. When you update a record in Xero, you generally send the complete object, and you use Xero’s own record IDs (GUIDs) rather than creating duplicates. This is the same class of gotcha that affects most accounting APIs: partial updates are not the norm, so your integration has to fetch, modify, and resend the full record, which is another source of avoidable egress if you are not careful.

When You Should Use the Xero API Directly, and When You Should Not

Not every Xero integration justifies building and maintaining the full stack yourself. Here is the framing.

Your situation	Recommended approach	Why
One-off data export or migration	Direct API calls, no persistence	Building sync infrastructure for a batch job is over-engineering
Connecting Xero to one or two common SaaS tools	Off-the-shelf connector or iPaaS	Faster and cheaper than custom code, if a connector exists
Connecting Xero plus several other accounting platforms	Unified API or custom middleware	One integration surface instead of many; normalizes the differences
Custom dashboard or analytics on Xero data	Sync to a warehouse, then build BI	Fast local queries, controlled egress, survives API changes
Deep, product-core Xero integration	Custom build with careful token and egress design	Full control where the integration is central to your product

The new pricing changes this calculus in one specific way: because egress now costs money, the “just call the API live from the dashboard” approach is more expensive than it used to be. Caching and warehousing, which used to be purely performance decisions, are now also cost decisions.

How to Build a Finance Dashboard on Xero Data

The most common Xero integration request I see is some version of: “We want a live dashboard of our financial position, pulling from Xero, ideally combined with our other systems.” It is a great proof of concept because it is small enough to ship in a few weeks and immediately useful. Here is a tool-agnostic blueprint built for the 2026 reality.

Pick the handful of numbers leadership actually watches. A strong finance dashboard answers one question: how healthy is the business this month? A typical set is revenue and gross margin, cash position, aged receivables (who owes you and how overdue), aged payables (what you owe), and a short runway or burn figure. Each gets a current value, a trend, and one drill-down. Resist the urge to rebuild all of Xero.
Map each number to its Xero source, and flag the gotchas early. Revenue and margin come from invoices and the profit-and-loss report. Cash comes from bank summary data. Receivables and payables come from the aged-report endpoints (remember: one contact at a time, so plan to reconstruct these from invoices instead). A cash flow figure has to be derived, because there is no endpoint for it. Naming these constraints in the first planning meeting saves a painful surprise later.
Sync to a warehouse, do not query Xero live. This is the step that matters most under the new pricing. Pull data from Xero on a controlled schedule into a small data warehouse, and have the dashboard read from the warehouse, never from Xero directly. Use the If-Modified-Since header so each sync pulls only what changed since the last run. This keeps you inside the rate limits, minimizes egress (and therefore cost), and means a Xero outage does not take your dashboard down. If you are storing periodic financial snapshots, a time-series store like TimescaleDB fits the shape of that data well.
React to changes with webhooks where they exist. For contacts and invoices, use Xero’s webhooks to trigger a targeted sync the moment something changes, rather than polling on a timer. For everything webhooks do not cover, fall back to a scheduled delta sync, a recurring background job that Solid Queue handles well in Rails. This hybrid is the standard shape of a well-built Xero integration.
Pick the visualization layer last. Power BI, Tableau, Metabase, Looker, a custom front end, they all work. An Xero Power BI integration and a Xero Tableau integration are the same project with a different final step. The one rule: in production the dashboard reads from your warehouse, not from the live Xero API, so you control both cost and performance.
Set governance and refresh expectations up front. Decide who sees what, and how fresh the numbers need to be. Finance dashboards rarely need real-time data; an hourly or daily refresh is usually plenty, and it keeps egress low. Be honest about the sync delay rather than implying the numbers are live to the second.

When Should You Build Reporting Outside Xero?

Build reporting outside Xero when you need to combine it with other systems, manage several Xero organizations, or run high-frequency queries that would burn through your egress allowance. Xero’s own reports are good, and for a single entity watching its own numbers they are often enough; they break down at multi-entity consolidation, cross-system blending, and frequent re-pulls. Recognizing those boundaries early saves a costly rebuild.

When you hit this	Stop doing this	Start doing this
You need to combine Xero with other systems	Living inside Xero’s reports	Sync to a warehouse and blend the data
Egress costs are climbing	Querying the live API for every view	Cache and warehouse, sync deltas only
You manage several Xero organizations	Logging into each one separately	Consolidate tenants into one reporting layer
You need custom or cross-entity metrics	Forcing Xero’s native reports to fit	Model the data in a warehouse
Leadership wants one screen	“Log into Xero and run three reports”	A dedicated dashboard on top of the warehouse

The pattern that wins is the same one that wins for most accounting and ERP platforms: keep the source system clean, replicate its data into a warehouse, model it once, and build reporting on top. Under Xero’s 2026 pricing, this pattern also happens to be the cheapest way to operate, because it minimizes the data you pull.

Case Study: Consolidating Three Xero Organizations

Picture a mid-sized professional-services firm running three legal entities, each in its own Xero organization, with around 90 staff across two countries. This is an illustrative composite, not a real client, but the shape is one I see often.

The problem. Every month the finance lead logged into three separate Xero organizations, exported profit-and-loss and aged-receivables reports from each, and stitched them together in a spreadsheet to produce a consolidated view for the partners. It took two full days, the numbers were a month stale by the time anyone saw them, and consolidating across three entities by hand was error-prone. The partners wanted one consolidated dashboard, refreshed weekly.

The approach. A three-phase project. First, scope the egress and pick the right Xero tier, since pulling three organizations’ worth of data monthly has a real cost under the new model, and design the sync to pull only what changed. Second, build the integration: a scheduled delta sync using the If-Modified-Since header for each organization, webhooks for invoice and contact changes, and aged receivables reconstructed from invoice data rather than the one-contact-at-a-time endpoint, all landing in a small managed warehouse with a clean consolidated data model. Third, deploy a single dashboard reading from the warehouse, showing consolidated and per-entity views with a weekly refresh.

Plausible outcomes. For projects of this shape, the consistent pattern is the elimination of the manual monthly assembly (here, the two-day spreadsheet cycle recovered every month), a shift from month-stale to current-week numbers, and a consolidated cross-entity view that simply did not exist before. The cost discipline designed in up front, syncing deltas rather than full pulls, keeps the ongoing Xero API bill predictable. Real results depend heavily on how clean the data is at the start, but the direction is reliable: when you stop hand-assembling reports across multiple Xero organizations, the time savings are immediate and large.

What to Do Now

If you are scoping a Xero integration in 2026, the short list is this. Estimate your data egress before anything else, because it now drives both your tier and your monthly cost. Design every sync to pull only what changed, using the If-Modified-Since header, since that single discipline controls rate limits and cost at once. Build token refresh carefully, because the 30-minute expiry is the most common point of failure. Use webhooks for the four event types that support them and poll for the rest. And if you have an existing Xero app, put the OAuth scope migration on the calendar now, ahead of the September 2027 deadline.

If you are building reporting on top of Xero, do not point your dashboard at the live API. Sync to a warehouse, model the data once, start with the handful of numbers leadership watches, and let the visualization tool be the last decision you make.

None of the hard parts of a Xero integration are technical. The work is agreeing which numbers finance will trust, how stale they are allowed to be, and pulling them without the egress meter running hot. Settle those early, and the technical build is the predictable half.

Need help building an integration on top of Xero or another accounting platform? I help teams with API architecture, data sync design, and reporting projects for financial data, including the cost and rate-limit design that the 2026 changes now demand. Reach out at [email protected].