What does a Xero integration developer actually build?
A Xero integration developer builds a small piece of software that reads from one system, applies your business rules and writes the result into Xero through its API, or the reverse. It runs on a schedule or reacts to events, and it records what it did so you can check it.
In New Zealand the requests are often similar. A retailer wants Shopify or WooCommerce orders to become invoices with the correct GST, and payment-provider payouts to reconcile cleanly. A clinic wants bookings to raise invoices automatically. A wholesaler wants its ordering portal to create invoices and pull payment status back. A trades business wants jobs from a job tool to flow into Xero with tracking categories for each branch.
The code itself is usually not the hard part. The hard part is agreeing exactly what should happen for every case: discounts, refunds, partial payments, gift cards, foreign-currency orders, zero-rated items and mistakes that need reversing. A good Xero integration developer spends real time on that before writing anything.
- Inputs: orders, bookings, jobs, deals, supplier data
- Rules: which contact, account, item, GST rate and tracking category
- Outputs: invoices, bills, credit notes, payments, bank transactions, contacts
- Safety: logs, alerts, retries and a way to replay a failed record
When should you hire a Xero integration developer instead of using the Xero App Store?
Hire a Xero integration developer only after checking that no App Store app, and no simple no-code workflow, already does what you need. Custom code is the right answer when your process is unusual, your volume is high, or the existing apps force you into workarounds that cost staff time every week.
Signs you have outgrown off-the-shelf connectors:
- Your accountant corrects GST or account codes on synced invoices every month
- The app summarises data in a way your reporting cannot use
- You pay for several apps that each handle part of one process
- A no-code workflow fails silently when volume spikes
- Your system is custom or niche, so no connector exists at all
- You need rules the app cannot express, such as branch-specific tracking
If the need is more workflow than accounting, compare our AI automation for NZ businesses, which often includes Xero steps.
Xero Custom Connections vs a public OAuth 2.0 app: which does your integration need?
Use a Custom Connection when the integration serves one Xero organisation, usually your own; use an OAuth 2.0 app when it must connect to several organisations. That single question settles most cases.
According to Xero's developer documentation, Custom Connections use the client credentials grant, connect to a single organisation, and are a premium option: the organisation buys a Custom Connection subscription. They are available to Xero organisations in Australia, New Zealand, the UK and the US, and can be connected to the Xero Demo Company free for development. Because Xero handles the authorisation, there is no user login flow to build.
A standard OAuth 2.0 app uses the authorisation code or PKCE flow, where a user signs in and approves access. It suits bookkeepers, franchise groups or software products that connect many organisations. Xero introduced app tiers from 2 March 2026, with a free Starter tier limited to 5 connections and paid tiers above it, while its pricing FAQ says Custom Connections stay on the same commercial terms and bespoke integrations built for a single client are exempt.
Xero's terms and prices change, so we confirm the current position on Xero's developer pricing FAQ when we scope your project.
Shopify and WooCommerce to Xero: what a custom sync should handle
A good store-to-Xero sync treats orders, refunds and payouts as three separate flows, because they happen at different times and settle into different accounts. Mixing them is the most common cause of messy reconciliation.
First decide the level of detail. Some businesses want one Xero invoice per order, with every line and discount. Others prefer one daily summary invoice per sales channel, which keeps Xero lighter and avoids hitting API limits on busy days. Your accountant should choose; we build either.
Then handle the awkward cases: partial refunds, exchanges, gift cards, shipping charged separately, orders in foreign currencies, and GST-inclusive prices that must be split correctly. Payouts from card and wallet providers arrive net of fees, so the sync usually records the gross sales, the fees as an expense and the net deposit against the bank feed.
Store builds themselves are covered on our Shopify developer NZ and WordPress developer NZ pages.
- Order to invoice (per order or daily summary)
- Refund to credit note, linked to the original
- Payout to bank transaction, with fees split out
- Product SKUs mapped to Xero items where useful
Syncing booking systems, job tools and CRMs into Xero
For service businesses, the Xero integration usually starts from a completed booking, job or won deal and ends as an invoice sent to the right contact. The key design choice is when the invoice is created and whether it starts as a draft for a human to check.
Clinics and studios often want invoices raised when an appointment is marked complete, not when it is booked, so cancellations do not create noise. Trades firms often want a draft invoice created from the finished job, reviewed in the office and then approved. Sales teams want new customers in the CRM to appear as Xero contacts, and paid or overdue status to flow back into the CRM so nobody chases a customer who has already paid.
Before we write code, we check what the other system offers: an API, webhooks, exports or only email notifications. That decides whether the integration can react instantly or needs to poll on a schedule. If the other tool has no usable API at all, we tell you rather than build something fragile.
Should a Xero integration be one-way or two-way?
Start one-way unless someone in your business genuinely needs Xero data back in the other system. One-way syncs are simpler to test, cheaper to build and easier to reason about when something looks wrong.
The most common reason to go two-way is payment status. Sales staff working in a CRM, or customers logging in to a portal, want to see whether an invoice has been paid without anyone opening Xero. In that case the integration writes invoices to Xero and reads back their status on a schedule, or reacts to change notifications where Xero offers them for that record type.
The trap is letting both systems edit the same fields. If a contact's address can be changed in the CRM and in Xero, which one wins? We settle that in the mapping sheet by naming one system as the source of truth for each field. Without that rule, two-way syncs quietly overwrite good data with stale data.
Historical data is a separate decision. Importing two years of old orders into Xero can clash with figures your accountant already entered by hand, so most businesses go live from a clean start date and leave history where it is.
- One source of truth per field, written down
- Read-back on a schedule sized to the API limits
- Clear start date so old records are not duplicated
GST, account codes and tracking categories: the mapping sheet
Every Xero integration developer should give you a mapping sheet before building: a table that says, for each type of transaction, which contact, account code, item, tax rate and tracking category it will use. You and your accountant approve it. The code follows the sheet.
GST in New Zealand is 15%, according to Inland Revenue. In Xero, tax rates are set up in each organisation, so the integration reads your organisation's tax rates through the API rather than assuming them. That matters for zero-rated exports, GST-free items and any lines your accountant treats differently.
We also decide how prices are sent: tax-inclusive or tax-exclusive, and how rounding is handled when a store's GST calculation differs from Xero's by a cent. Small rounding rules, agreed upfront, save hours of month-end head-scratching.
We do not give tax advice. Which tax rate applies to a given sale is your accountant's call; our job is to apply the rule they choose, consistently, every time.
Xero API rate limits and error handling: how a reliable integration behaves
Xero limits how fast an integration can call its API, and a reliable integration is designed around those limits from day one. Xero's limits FAQ lists 60 calls per minute and 5,000 calls per day for each connected organisation, 5 calls in progress at once, and an app-wide limit of 10,000 calls per minute.
When a limit is hit, Xero returns HTTP 429 “Too Many Requests” with a Retry-After header saying how many seconds to wait, and an X-Rate-Limit-Problem header naming the limit. We build the integration to respect that header, queue work and resume, rather than hammering the API and failing. Xero also says its limits cannot be increased, so the design has to fit inside them.
Practical tactics: batch several records into one request where the endpoint allows it, only fetch records modified since the last run, avoid re-reading data you already have, and spread heavy imports over quieter hours.
- Queue every record, never fire and forget
- Respect Retry-After on HTTP 429 responses
- Log each attempt with the source record ID
- Alert a person when a record fails validation, not only when the API is down
- Provide a simple way to re-run one failed record
How much does a Xero integration developer cost for an NZ business?
With us, a focused one-direction Xero sync starts from US$600 and usually takes two to four weeks; two-way integrations or multi-organisation apps with admin screens start from US$900. Other developers' quotes vary widely, and the difference usually comes from scope clarity rather than hourly rates.
These are the factors that move the price most:
- Number of source systems and directions of sync
- How many edge cases the mapping sheet has to cover
- Historical data import and clean-up
- Whether an admin screen, dashboard or approval step is needed
- Volume, which affects batching and queue design
- Hosting preferences, such as an Australian or NZ cloud region
Running costs are separate and sit in your accounts: hosting, any Custom Connection subscription Xero charges, and the other system's API plan if it has one. Maintenance is free for two months after launch, then from US$120/mo if you want us to keep watching it. See all plans on our pricing page.
How a custom Xero integration is built, step by step
The build runs in five stages: map, prototype on the Demo Company, test with real data, go live on your organisation, then monitor. Nothing touches your live Xero file until you have seen it work on test data.
1. Mapping workshop
A video call with you and, ideally, your accountant. We leave with a draft mapping sheet and a list of edge cases.
2. Demo Company prototype
The integration is built against Xero's Demo Company, so we can create, change and delete records freely.
3. Parallel test
A week or two of real source data processed into a test organisation or reviewed as drafts, compared against what your team would have entered.
4. Go live
Switched to your organisation with credentials you created, usually starting from a clean date so historical records are not duplicated.
5. Monitor
Daily logs and alerts reviewed for the first weeks, then weekly. Fixes during the five free maintenance months.
Who owns a custom Xero integration and its credentials?
You should own everything: the Xero developer app or Custom Connection, the client ID and secret, the hosting account, the code repository and the logs. A Xero integration developer who registers the app under their own account can switch it off, and moving it later means re-authorising everything.
We ask you to create the app or Custom Connection in your own Xero developer account and share access with us for the build. Hosting sits in your cloud account. Code lives in a repository you own. At handover you get a short technical document: what runs, when, where the logs are, how to rotate credentials and how to re-run a failed record.
If we stop working together, any competent developer can pick up the integration from that document and the code. That is the test worth applying to any supplier.
Security and privacy: customer and financial data flowing through an integration
An integration handles money and personal information, so it should request only the Xero permissions it needs, store tokens and secrets encrypted, and keep logs free of anything more sensitive than an ID where possible.
New Zealand's Privacy Act 2020 applies to personal information your business sends through the integration, and Principle 12 covers disclosure to overseas recipients; the Privacy Commissioner explains when that is allowed. To support your obligations, the integration runs in your own cloud account, in a region you choose, and our access is removed when the work ends.
We are not auditors or lawyers. How your privacy statement describes these flows, and whether they meet your obligations, is for you to confirm with your own adviser.
- Least-privilege scopes on the Xero app
- Secrets in a managed secret store, not in code
- HTTPS everywhere, with signed webhooks verified where used
- Logs that store record IDs, not full customer details
- Access for developers removed at handover
Where should a Xero integration run?
Most Xero integrations run happily as small scheduled or event-driven functions in a cloud account, costing little to run. The choice between serverless functions, a small server or an existing platform depends on volume and what else you already host.
Another of us, who handles our AWS and data work, usually suggests a serverless set-up for scheduled syncs: functions triggered on a timer or by webhooks, a queue for records waiting to be sent, and a small database table for the log. NZ businesses often choose an Australian or New Zealand cloud region to keep data close; we set it up where you prefer.
If your business already runs a custom portal or app, the integration can live inside it instead. That is common when we are also building the portal, covered on our custom software for NZ SMEs page.
How to choose a Xero integration developer: questions to ask
Choose the developer who asks the most questions about your accounting rules and edge cases, not the one who promises the fastest build. Integrations fail at the edges.
- Will you give us a mapping sheet to approve before building?
- Custom Connection or OAuth 2.0 app, and why?
- How do you handle Xero's 429 responses and daily limits?
- What happens to a record that fails, and who is told?
- Will the app, credentials, hosting and code be in our name?
- How do you test without touching our live Xero file?
- What does it cost to run each month, and who pays each bill?
- What does maintenance look like when Xero changes something?
Our general guide to hiring an API developer covers the same questions for other systems.
Red flags in Xero integration quotes
The clearest red flag is a quote with no mention of mapping, testing or error handling. That quote is pricing the happy path only, and the unhappy paths are where your accountant's time disappears.
- The developer registers the Xero app under their own account
- No plan for refunds, credit notes or partial payments
- Tax rates hard-coded rather than read from your organisation
- Straight to your live Xero file without a Demo Company phase
- No logs you can read, or logs only the developer can access
- Hosting billed through the developer with no way to take it over
- A promise that it will never need maintenance
Working with a Xero integration developer in India from New Zealand
Integration work suits a remote team because it is almost entirely screen-based: calls, a shared mapping sheet, test runs and logs. You need to be available for questions about your rules; you do not need anyone in your office.
New Zealand is six and a half hours ahead of India, or seven and a half during NZ daylight saving. We book calls in your afternoon, which is our morning, and run test syncs through our day so results are waiting for you. WhatsApp is open seven days a week.
Quotes are in USD and paid by Wise, bank wire or PayPal against milestones in the written quote, with nothing billed before you approve it. Invoices come from India; your accountant can advise how to record them. The first two weeks usually cover the mapping workshop, Demo Company prototype and first test results.
Worked example: a hypothetical Christchurch retailer syncing Shopify into Xero
Suppose an outdoor gear retailer in Christchurch sells through Shopify and one shop counter, and its bookkeeper spends hours each week keying order totals and reconciling card payouts. This is an illustrative scenario, not a client story.
After the mapping workshop, the bookkeeper chooses daily summary invoices per channel rather than one invoice per order. Refunds become credit notes against the same summary contact. Card payouts are recorded as gross sales less fees, with the net matched against the bank feed. Gift card sales go to a liability account, not revenue. Tax rates are read from the organisation, and a rounding rule is agreed for the odd cent.
Because it serves one organisation, a Custom Connection fits, set up under the retailer's own Xero account. The sync runs nightly in the retailer's cloud account, logs every order ID, and emails the bookkeeper if a record fails validation.
That scope sits in the automation plan from US$600, around three weeks including the parallel test. If the retailer later wanted stock levels synced both ways with a supplier portal, that would become a larger build from US$900.