DEV Community: ilshaad

Cron Scripts vs Managed Sync: The Hidden Cost of Rolling Your Own

ilshaad — Tue, 22 Sep 2026 09:54:14 +0000

A cron job and 50 lines of Node looks free. Here is what building and running your own billing data pipeline really costs, and when managed sync is cheaper.

By Ilshaad Kheerdali · 22 September 2026

Every developer who has needed billing data in their own database has had the same thought, usually within about ninety seconds of looking at a pricing page: I could write this myself in an afternoon.

You are right. You could. The afternoon version genuinely works, and that is the problem, because the afternoon is not the cost. The cost is the eighteen months afterwards, and it lands in places that never appear in the build estimate: somewhere to run the thing, someone to notice when it stops, and a slow drip of maintenance that never quite ends.

This post puts real numbers on that. Not to argue that you cannot build it, but so you can compare the two options honestly before you commit.

The Script That Works on Day One

Here is the version everyone writes. It is not a strawman, it is genuinely what a competent developer produces in an afternoon, and it does work.

// sync-stripe.js
import Stripe from 'stripe';
import { Client } from 'pg';

const stripe = new Stripe(process.env.STRIPE_SECRET_KEY);
const db = new Client({ connectionString: process.env.DATABASE_URL });

await db.connect();

const customers = await stripe.customers.list({ limit: 100 });

for (const c of customers.data) {
  await db.query(
    `INSERT INTO stripe_customers (id, email, name, created)
     VALUES ($1, $2, $3, to_timestamp($4))
     ON CONFLICT (id) DO UPDATE SET email = $2, name = $3`,
    [c.id, c.email, c.name, c.created]
  );
}

await db.end();

One crontab line and it is a pipeline:

0 2 * * * /usr/bin/node /srv/sync/sync-stripe.js

Run it, and rows appear in Postgres. The demo is convincing. If your Stripe account has 80 customers and you only ever need customers, you can genuinely stop here, and you should.

What the Script Quietly Does Not Handle

The script above is correct for exactly one shape of data: a single small table, fetched whole, with no failures. Every assumption in that sentence breaks at some point.

Pagination. limit: 100 is the maximum page size, not the maximum table size. Past 100 customers you are silently syncing a fraction of your data, and nothing errors. You need has_more and cursor loops on every list call.

Rate limits. Stripe's published limits are 100 requests per second in live mode, but the constraint that actually bites is the read allocation, which scales with your transaction volume and has a floor of 10,000 reads a month. Xero is stricter, with a per-tenant daily call cap. Hit either and your script does not slow down gracefully, it throws. You need backoff, retry with jitter, and a way to resume a half-finished run.

Incremental fetching. Re-reading every invoice every night stops being viable somewhere in the low tens of thousands of rows. So you add a watermark, and then you discover the genuinely hard part: updated_at semantics differ per provider, some objects do not expose one at all, and a naive "since last run" bookmark loses data permanently the first time a run fails. Fixed lookback windows are more robust than bookmarks, which is why we default to them.

Deletions and amendments. An upsert never removes anything. Delete a customer in Stripe, void an invoice in Xero, amend last quarter's entry in QuickBooks, and your table keeps the stale row forever. Accounting systems do this constantly, and it is the failure mode most likely to put a wrong number in front of your finance team.

Schema drift. Providers add fields. Your INSERT has a fixed column list, so new fields are dropped silently, and the day you want one you are writing a migration and a backfill.

Type handling. Stripe returns amounts as integers in the smallest currency unit and timestamps as Unix seconds. Get the conversion wrong once and every revenue figure downstream is out by a factor of 100. Nested objects need a considered jsonb policy rather than a JSON.stringify reflex.

Secrets and connections. process.env on a box you SSH into is fine until it is not. Long-lived API keys need rotating, OAuth providers like QuickBooks and Xero need refresh-token handling with the refresh persisted somewhere durable, and a script that reconnects to Postgres on every run will exhaust a pooled connection limit faster than you expect.

None of these is hard. That is exactly the trap. Each one is a two-hour job, and there are nine of them, and you find them one at a time over six months, each announced by a number that looks slightly wrong.

Somewhere to Run It: The Infrastructure Nobody Budgets

This is the cost that gets left out of every build-versus-buy estimate, because crontab -e feels free. It is not free, it is just unpriced. Your script has to live somewhere, and every option has a real bill and a real failure mode.

Your laptop. Free, and it works until you close the lid. Not a serious option, but worth naming because a surprising number of pipelines start here and quietly stay here.

A small VPS. The honest baseline. A DigitalOcean basic droplet starts at $4 a month for 512 MiB and 1 vCPU, which is ample for a nightly sync. The bill is not really $4 though, it is $4 plus a machine you now own: OS patches, Node version upgrades, disk filling with logs, and a box that is invisible to your team until it is the reason the numbers are stale.

GitHub Actions on a schedule trigger. Genuinely appealing, and the most common free choice. Read the documentation carefully first. GitHub states that the shortest interval is once every 5 minutes, that "the schedule event can be delayed during periods of high loads", that "if the load is sufficiently high enough, some queued jobs may be dropped", and that in a public repository scheduled workflows are automatically disabled after 60 days of no repository activity. A scheduler that may silently drop your run, and may switch itself off, is a poor foundation for the table your MRR dashboard reads from. Private repositories on the Free plan include 2,000 minutes a month, after which Linux runners bill at $0.006 a minute.

Serverless functions on a scheduler. Cheap per invocation and pleasantly hands-off, until a full backfill runs past the execution timeout. Then you are writing checkpointing and chunking, which is a genuine engineering project rather than a cron line.

Whichever you pick, you still need the part that is not the schedule: somewhere to see whether last night's run succeeded, and something that tells you when it did not. A cron job that fails is completely silent by default. The realistic failure is not a dramatic outage, it is a script that has been dying at 2am for three weeks while everyone kept reading the dashboard it feeds. We covered why these pipelines break in production in more detail.

Run history and alerting is the piece people defer indefinitely, and it is the piece that decides whether you can trust the data.

What Building a Data Pipeline Actually Costs

Put hours against it. These are for a developer who knows the stack, building one provider properly, with no padding for the parts they have not met yet.

Piece	Hours
First working script, one table	4 to 8
Pagination and initial backfill	3 to 6
Rate-limit backoff, retries, resumable runs	4 to 8
Upserts, deletions, amendment handling	4 to 8
Incremental windows	4 to 8
Secrets, OAuth refresh, multi-table config	3 to 6
Deploy target and scheduling	3 to 8
Run history and failure alerting	4 to 8
Total	29 to 60

IT Jobs Watch puts the UK median backend developer contract day rate at £525 for the six months to 20 September 2026, which is roughly £70 an hour. That makes the build £2,000 to £4,200, or about $2,700 to $5,700.

If you are a founder writing it yourself, substitute your own number, but do not substitute zero. Those 29 to 60 hours are a week to a week and a half of full-time work not spent on the product, and that is the expensive part, not the cash.

Then add the running cost: $4 to $20 a month for compute, plus whatever your monitoring costs once you stop pretending you will check the logs by hand.

And that is one provider. Adding QuickBooks or Xero afterwards is not a copy-paste, because OAuth, tenant handling and pagination semantics are all different.

The Maintenance Line That Never Ends

The build is finite. The maintenance is not, and this is the number that decides the argument.

Every month there is something. An API version deprecation with a migration window. A new field finance wants, which means a migration plus a backfill. A refresh token that expired while someone was on holiday. A rate limit you started hitting because the business grew. A Node or dependency upgrade on that droplet. A run that failed at 2am and needs replaying by hand.

Call it 2 to 4 hours a month once things have settled down, which is conservative. At £70 an hour that is £140 to £280 a month, every month, indefinitely. It is invisible in any budget because it is never a line item, it is just a Tuesday morning that went somewhere.

Over two years, the build plus that maintenance comes to somewhere between £5,400 and £10,900, ignoring compute.

When Rolling Your Own Is the Right Call

It genuinely is sometimes, and the cases are specific:

You need one small table and nothing else, ever. Eighty customers, one nightly pull. The script at the top of this post is the correct answer, and buying anything would be silly.
Your transformation is the actual product. If the point is bespoke enrichment, or joining three sources into a proprietary shape mid-flight, you were going to write code regardless.
You already run a pipeline platform. If Airflow or Dagster is up with alerting and an on-call rota, one more DAG is a genuinely small marginal cost. The infrastructure section above is already paid for.
Compliance forbids third-party credential access. A hard constraint is a hard constraint.

Notice what those have in common: either the work is trivially small, or the expensive infrastructure already exists. Outside those, you are paying to rebuild something undifferentiated.

What Managed Sync Costs Instead

Codeless Sync exists to be the other side of that comparison, so here is the pricing plainly.

Starter is $19 a month and Pro is $29, both with daily, weekly and monthly schedules, and 10 and 30 configurations respectively. Business is $99 and adds twelve-hourly scheduling. There is a free tier with two manual syncs a day while you evaluate it.

The comparison over two years:

	Build it	Codeless Sync Pro
Up-front	£2,000 to £4,200	£0
Compute	$4 to $20 a month	Included
Maintenance	£140 to £280 a month	£0
Alerting and run history	You build it	Included
Adding a second provider	Most of another build	A configuration
Two-year total	£5,400 to £10,900	about £550

Pagination, backoff, upserts, deletion handling, lookback windows, OAuth refresh, run history and failure alerting all sit on our side of the line. Destination tables are created for you, and the schedule is a dropdown rather than infrastructure. If you want the cron syntax behind those presets, we wrote that up separately.

The quick start takes about five minutes, which is a useful benchmark against the afternoon.

Frequently Asked Questions

Is it cheaper to build your own data pipeline or use a managed sync tool?

For a single small table you pull occasionally, building it is cheaper, and a 20-line script does the job. Past that, managed sync wins quickly. A properly built pipeline for one provider runs 29 to 60 developer hours up front and 2 to 4 hours a month to maintain, which at UK median contract rates is £2,000 to £4,200 to build and £140 to £280 a month to keep. Managed sync starts at $19 a month with no build.

Can I just use a GitHub Actions cron job for free?

You can, with caveats worth knowing first. GitHub documents that scheduled workflows may be delayed under high load, that queued jobs may be dropped entirely when load is high enough, and that scheduled workflows in public repositories are disabled automatically after 60 days without repository activity. Private repositories on the Free plan get 2,000 minutes a month. It is fine for something you can afford to miss, and a poor choice for a table your reporting depends on.

What usually breaks first in a homemade sync script?

Pagination, and it breaks silently. A list call with limit: 100 returns the first page whether you have 80 records or 80,000, with no error raised. The second is deletion handling: upserts never remove rows, so voided invoices and deleted customers linger indefinitely. Both surface as numbers that are slightly wrong rather than as a failure, which is why they survive so long.

How long does it really take to build a Stripe to Postgres sync?

The first working version takes an afternoon. A version you would trust your revenue reporting to takes 29 to 60 hours, because pagination, rate-limit backoff, incremental windows, deletions, schema drift, secrets handling, deployment and alerting are each small jobs that you meet one at a time over several months.

Does this change if I need more than one provider?

It gets worse, not better. A second provider is not a copy-paste: QuickBooks and Xero use OAuth with refresh tokens rather than a static key, Xero adds per-tenant handling and a stricter daily call cap, and pagination semantics differ across all four. Expect most of another build per provider. With managed sync it is a new configuration.

The Honest Comparison

The choice is not "write 50 lines" versus "pay $19 a month". It is "own a small piece of infrastructure indefinitely" versus "pay $19 a month".

If that infrastructure is load-bearing for your product, own it. If it is a table your dashboard reads so you can look at MRR without opening four tabs, the maintenance line is the whole argument, and it is the one nobody prices until they are already paying it.

Worth doing the arithmetic before the afternoon, rather than eighteen months into it.

Is It Safe to Connect Stripe or QuickBooks to a Third-Party Sync Tool?

ilshaad — Tue, 15 Sep 2026 10:11:32 +0000

How to judge whether a billing sync tool deserves your Stripe or QuickBooks credentials, what to ask before connecting, and how to verify it after.

By Ilshaad Kheerdali · 15 September 2026

You have found a tool that syncs your billing data into your own database, the setup takes five minutes, and the last screen asks for a Stripe key. That is the moment most people stop and think about it properly for the first time.

It is the right instinct. You are about to give a company you found twenty minutes ago standing access to every customer, invoice and payment in your business. "Is it safe" is a reasonable question, and the honest answer is that it depends entirely on things you can check before you click connect.

This post is that check. It covers what you are actually handing over, the four ways a tool can hold your credentials ranked from worst to best, the questions worth asking any vendor, and, most usefully, how to verify the answers yourself instead of taking anyone's word for it. We run one of these tools, so we answer every question about ourselves along the way, including the two answers that are not flattering.

What You Are Actually Handing Over

The first thing worth being precise about: you are not handing over your data. You are handing over a credential, and the credential is what determines how much damage is possible.

That distinction matters because the risks people worry about and the risks that actually occur are different. Almost nobody is hurt by a sync vendor deliberately misusing their data. The realistic failure modes are duller:

The vendor gets breached, and your credential is in the blast radius.
The credential has more permission than the job needs, so a breach that should have leaked read access leaks write access instead.
You forget the connection exists, leave the company, change tools, and the credential stays live for three years.
The vendor stores the credential badly, in plain text or in application logs, so a low-severity incident becomes a high-severity one.

Every one of those is a question about the credential, not about the vendor's intentions. Which is good news, because credentials are something you can inspect, scope, monitor and revoke on your own, without trusting anybody.

The Four Credential Models, Worst to Best

Sync tools ask for access in one of four ways. The difference between the worst and the best is enormous, and it is visible before you sign up.

1. Full secret key. A tool asks for your Stripe sk_live_ key or the equivalent. This is the whole account: read everything, create charges, issue refunds, update subscriptions. Stripe's own documentation is blunt about it, saying that because you cannot limit their permissions, it does not recommend secret keys for new use cases and recommends migrating existing integrations to restricted keys. Its restricted key guide puts it more directly still, describing a secret key handed to a third party as dangerous because it gives that third party full control, against a restricted key that hands over only the access they need. If a tool insists on a full secret key in 2026, that tells you something about how much thought went into the rest of it.

2. Restricted key. Same mechanism, but the key carries only the permissions you granted it. A read-only restricted key that leaks is an information disclosure problem. A secret key that leaks is a money problem. Stripe calls these RAKs and they are the recommended default. Paddle works similarly with scoped API keys.

3. OAuth with a broad scope. No key changes hands at all. You authorise through the provider, the provider issues the tool a token, and you can see and revoke that grant from your own account without contacting the vendor. The catch is that some providers only offer coarse scopes, so "broad" can still mean write access.

4. OAuth with a read-only scope. The best available. No key to leak, revocable by you at any time, and the token is cryptographically incapable of changing anything.

The practical ranking is simple: prefer OAuth where the provider offers it, insist on a restricted key where it does not, and treat a full secret key request as a red flag rather than a minor inconvenience.

What Codeless Sync Asks For, Provider by Provider

Here is our own answer to the question, which is only useful if it includes the parts we would rather leave out.

Provider	Method	Scope requested	Honest assessment
Stripe	Restricted key	Read-only, created through Stripe's "providing this key to another website" flow	Best available for Stripe, which does not offer OAuth for this use case
Xero	OAuth 2.0	`accounting.transactions.read`, `accounting.contacts.read`, `accounting.settings.read`, `accounting.journals.read`	Genuinely read-only, the strongest of the four
QuickBooks	OAuth 2.0	`com.intuit.quickbooks.accounting`	Read and write. Intuit publishes no read-only accounting scope. See below
Paddle	API key	Read-only key	Comparable to the Stripe position

The QuickBooks answer needs saying plainly. Intuit's accounting scope is a single permission covering both reading and writing. There is no read-only variant to request, so every QuickBooks integration on the market, ours included, holds a token that could in principle write to your books. Any vendor claiming read-only QuickBooks access is either confused or misleading you.

What we can tell you is that we never use it. Codeless Sync issues no write call to any provider. The only non-read request in our entire worker is the OAuth token refresh that keeps the connection alive. The section below tells you how to confirm that for yourself rather than believe it because we wrote it down.

For Stripe we go a step further than most: our setup instructions point you at Stripe's purpose-built flow for exactly this situation, the one where you tell Stripe you are providing a key to a named third party and it scopes the key appropriately, and our instructions explicitly tell you not to tick "customize permissions". Fewer decisions, fewer ways to accidentally grant write access.

What Happens to the Credential After You Paste It

Storage is where most of the real risk sits, and it is the part vendors are usually vaguest about. Ours:

Encrypted at rest with AES-256-GCM, an authenticated cipher, with a random initialisation vector per credential. Authenticated means tampering with the stored ciphertext is detected rather than silently decrypted into something else.
TLS 1.3 in transit, both to us and from us to your database.
Decrypted only in memory at sync time, to make the API calls the sync needs.
We are a UK company and handle personal data under UK GDPR. Our privacy policy sets out what we hold and for how long.

"Encrypted at rest" is close to meaningless as a marketing phrase, so the useful follow-up when you are evaluating any vendor is which cipher and where the key lives. A vendor that cannot answer that in one sentence has probably not thought about it.

Seven Questions to Ask Any Sync Vendor

These work on us and on our competitors. If a vendor cannot answer them from their public documentation, that is itself an answer.

What is the least-privileged credential you accept? If the answer is a full secret key, stop.
Which exact OAuth scopes do you request, by name? Vague answers like "read access to your accounting data" are not scope names. Real scopes are strings you can look up.
Do you ever write to my source system? Ask it directly, and ask how you can verify it.
Which cipher encrypts credentials at rest, and where does the encryption key live?
What happens to my credentials when I close my account?
Where does my data actually go? In a sync tool it should land in a database you own, which means the vendor holds a credential but is not accumulating a copy of your business. That is a meaningfully smaller target than a vendor that warehouses your data on their own infrastructure.
How do I revoke access without contacting you? If revocation requires a support ticket, the vendor has more control over your data than you do.

Question six is the one people miss, and it is the structural argument for this category of tool. A sync tool that writes into your own PostgreSQL is holding a key to your house rather than moving your furniture into their warehouse. When you disconnect it, your data is still in your database, because it was always in your database.

How to Verify the Answers Yourself

This is the part that makes the rest of the post worth something. You do not need to trust a vendor's claims, including ours, because all three major providers let you audit third-party access from your own account.

Stripe: read the request log for the key. Every restricted key has its own request log. In the Dashboard, open Developers → API keys, click the overflow menu on the key you issued, and choose View request logs. You will see every call made with that key, with method and endpoint. Stripe documents the mapping plainly: GET is a read, while POST and DELETE are writes. So if a vendor claims read-only behaviour, this is where you confirm it, and you should see GET requests and nothing else. Check it a week after connecting, then whenever you feel like it.

Stripe: pin the key to the vendor's infrastructure. Less well known, and genuinely useful. Stripe supports access policies that restrict a key by IP range, ASN or country, and block anything else while notifying you. Attach one to the key you gave your sync vendor and a stolen credential becomes far less useful to whoever stole it. Stripe recommends policies on all live-mode keys, and almost nobody does it.

Stripe: rotate on your own schedule. Rotating a key keeps both the old and new key working for up to seven days, so you can rotate a vendor's credential without downtime and without asking permission. If a vendor's integration breaks when you rotate a key, you have learned something useful about it.

Xero and QuickBooks: check the connected apps screen. Both show every application connected to your organisation, what it can access and when it was authorised. Review it periodically, the same way you would review who has keys to the office. If you run several client organisations, each one is authorised separately, which is a feature rather than an annoyance: revoking one client leaves the rest untouched. We wrote about that structure in more detail in syncing multiple Xero organisations into one database.

Everywhere: check what happens when you disconnect. Connect a tool, sync once, disconnect it, and confirm your data is still sitting in your own database. If disconnecting takes your data with it, you were renting access to your own records.

What We Do Not Have

An honest trust page has to include the gaps, because the gaps are what a careful reader is looking for anyway.

We do not have SOC 2 or ISO 27001. We are a small UK company, and those certifications cost tens of thousands of pounds and months of auditor time. We would rather spend that on the product at this stage. If your procurement process requires a SOC 2 report, we will fail it, and you should use a vendor that has one.

What we would gently push back on is treating a certification as the same thing as security. SOC 2 attests that a company follows the controls it says it follows. It is a strong signal about organisational maturity and a weak signal about whether a specific integration asks for more permission than it needs. The seven questions above tell you more about your actual exposure than a badge does, and they work on certified vendors too.

We are a small team. That cuts both ways honestly: a smaller attack surface and less to steal, but no dedicated security staff and no 24-hour incident response. Weigh that as you see fit. It is the same trade you make with most tools at this price point, and it is a reason to give us a read-only, revocable, monitored credential rather than an unrestricted one, which is what we ask for anyway.

How to Revoke Access

Worth knowing before you connect rather than after.

Stripe. Expire or rotate the restricted key in Developers → API keys. Access stops immediately on expiry. Because we use a key rather than Stripe Connect, revocation is entirely in your hands and does not involve us.
Xero. Disconnect Codeless Sync from your organisation's connected apps settings. Each organisation is revoked separately.
QuickBooks. Disconnect from the connected apps list in your Intuit account.
From our side. Delete the connection in your Codeless Sync dashboard and the stored credential goes with it. Deleting your account removes them all.

In every case, the tables already synced into your database stay yours, because they were never anywhere else.

Where This Leaves You

The question is not really "is it safe to connect a third-party sync tool". It is "what is the smallest amount of access this job needs, and can I see and revoke it". Asked that way it stops being a matter of trust and becomes a matter of configuration, which is a much better position to negotiate from.

For a billing sync specifically, the job needs read access to billing objects and nothing else. That is available on Stripe, Xero and Paddle today, and unavailable on QuickBooks for reasons that belong to Intuit rather than to any vendor. Give a tool exactly that, put it somewhere you can watch it, and check the log occasionally.

If you want to see what the connection looks like before committing anything, our Stripe setup guide walks through creating the restricted key, and you can do the whole thing on a Stripe sandbox key first. A sandbox key exercises the entire flow with no live data attached, which is the cheapest possible way to audit a vendor.

Frequently Asked Questions

Is it safe to give a third-party tool my Stripe API key?

It depends on which key. A restricted, read-only key is a reasonable thing to share with a vendor you have checked, because the worst case is disclosure of data the vendor was reading anyway, and you can expire it yourself at any moment. A full secret key is not, because it can move money. Stripe itself recommends restricted keys over secret keys for new integrations.

Can a sync tool change or delete my Stripe or accounting data?

Only if the credential you gave it allows writes. A read-only restricted Stripe key cannot, and neither can Xero's read scopes. QuickBooks is the exception, because Intuit's accounting scope covers read and write with no read-only alternative, so the protection there is the vendor's behaviour rather than the token. Check the request log or your connected apps screen rather than relying on assurances.

How do I know a sync tool is not writing to my account?

Read the request log. Stripe records every call made with each restricted key, viewable from the API keys page in your Dashboard, and read-only behaviour shows up as GET requests with nothing else alongside them. This is the single most useful habit in this whole post, and it takes about a minute.

Does Codeless Sync store a copy of my billing data?

No. Data moves from the provider into the PostgreSQL database you own and control, on Supabase, Neon, AWS RDS, Railway, DigitalOcean or anywhere else. We hold the credential needed to run the sync and the configuration describing it, not a warehouse of your records. Disconnecting leaves every synced table exactly where it is.

Is OAuth safer than an API key?

Usually, for two reasons that have nothing to do with cryptography: no secret is copied and pasted through a browser and an email client on its way to the vendor, and you can revoke the grant from your own account without involving them. The exception is a coarse OAuth scope that grants more than a well-scoped API key would, which is precisely the QuickBooks situation.

Do you have SOC 2 certification?

No. We are a small UK company and have not been through a SOC 2 or ISO 27001 audit. We handle personal data under UK GDPR, encrypt credentials at rest with AES-256-GCM and use TLS 1.3 in transit. If your procurement requires a SOC 2 report, we are not the right supplier yet.

What happens to my credentials if I stop using the service?

Deleting a connection removes the stored credential, and deleting your account removes all of them. You do not have to rely on that alone, which is the point of the section above: expire the Stripe key or disconnect the app from Xero or QuickBooks and access ends immediately, regardless of what any vendor does on their side.

Wrapping Up

The safest posture with any sync tool is not trusting the right vendor. It is granting the least access the job needs, in a form you can watch and withdraw on your own.

Ask the seven questions. Insist on a restricted or read-only credential. Read the request log a week later. Do that and the answer to "is it safe" stops depending on marketing copy, including ours.

If our answers hold up, start with a Stripe sandbox key and watch exactly what the integration does before you give it anything live.

Related:

How to Sync Multiple Xero Organisations into One Database

ilshaad — Mon, 07 Sep 2026 11:35:46 +0000

If you look after more than one Xero organisation, you already know the drill. Log into the first org, run the report, export it. Log out. Log into the second org, run the same report, export it again. Paste six exports into a spreadsheet and hope nobody asks you to refresh it next week.

This is not a workflow problem you are failing to solve. Xero is built around one organisation at a time, and consolidated reporting across organisations is a long-standing request that Xero has not committed to building. Every accountant, bookkeeper and agency running several client files hits the same wall.

There is a way out that does not involve a spreadsheet: put every organisation's data into one PostgreSQL database, tagged by organisation, and query the lot with SQL. This post covers why Xero makes it awkward, the one schema decision that makes it work, and what to watch for when you consolidate across clients.

Why Xero Makes This Awkward

Xero treats each organisation as a separate world, and its API is built the same way.

When you authorise an app against Xero, you are not authorising an account, you are authorising a set of organisations, each identified by a tenant ID. Every single API call then has to name which organisation it is for, by passing that tenant ID in a header. Get it wrong and you do not get an empty result, you get an error.

That design is sensible. An accountant with forty client files should not be able to leak one client's ledger into another's report by forgetting a filter. But it means anything that reads Xero data has to be built for multiple organisations from the start, and most things are not. The mechanics of the OAuth flow and the tenant header are covered in our Xero API integration guide if you want the developer-level detail.

The result is a market full of tools that connect to one organisation nicely and fall apart at five.

The One Schema Decision That Makes This Work

Here is where most home-grown attempts go wrong. Faced with several organisations, the instinct is to give each one its own table, or worse, its own database. acme_invoices, globex_invoices, initech_invoices, on and on.

It works for two clients. At ten it is a maintenance problem, because every new client means new tables, every query means a UNION across a list you have to keep updating, and every schema change has to be applied everywhere.

The alternative is one table per data type for all organisations, with the tenant ID carried as a column and folded into the primary key. Codeless Sync builds its Xero tables this way: the primary key is the composite (id, tenant_id), and tenant_id is indexed. Two organisations can hold a contact or an invoice with the same Xero ID without colliding, and every table is one query away from being filtered or grouped by organisation.

That single choice is what turns "six exports and a spreadsheet" into GROUP BY.

The second piece is the xero_organisations table. Xero exposes organisation metadata as a data type of its own, so you can sync it alongside the rest and get a row per organisation carrying the trading name, legal name, base currency, country code, financial year end month and timezone, keyed by the same tenant_id. Without it your consolidated queries are full of GUIDs. With it they read like a client list.

Setting It Up

The shape of the job, assuming you are not writing the sync yourself:

Connect each organisation. Authorise Xero once per organisation you want to sync. Where you have access to several, you pick which one this connection is for.
Choose the data types. Contacts, invoices, payments, accounts, bank transactions, credit notes, items, purchase orders, journals and organisations are all available. Most consolidated reporting needs fewer than you think: invoices, contacts and organisations covers a surprising amount.
Create the destination tables once. Not once per client, once. Every organisation writes into the same tables, separated by tenant_id. Tables can be auto-created, or you can run the SQL templates yourself if you would rather see the DDL first.
Put it on a schedule. Daily is the sensible default for accounting data. Our post on how often to sync billing data covers picking a cadence properly.

If you have never done the single-organisation version, how to sync Xero to PostgreSQL walks the whole flow start to finish. Multi-organisation is that, repeated per client, into the same tables.

The Queries That Make It Worth Doing

This is the part that pays for the setup. All three of these are impossible in Xero's own reporting because they cross organisations.

Outstanding receivables, every client, one screen.

SELECT
  o.name AS organisation,
  i.currency_code,
  count(*) AS open_invoices,
  sum(i.amount_due) AS outstanding
FROM xero_invoices i
JOIN xero_organisations o ON o.tenant_id = i.tenant_id
WHERE i.type = 'ACCREC'
  AND i.status = 'AUTHORISED'
GROUP BY o.name, i.currency_code
ORDER BY outstanding DESC;

Who is overdue, across the whole book.

SELECT
  o.name AS organisation,
  i.invoice_number,
  i.contact_name,
  i.due_date,
  current_date - i.due_date AS days_overdue,
  i.amount_due,
  i.currency_code
FROM xero_invoices i
JOIN xero_organisations o ON o.tenant_id = i.tenant_id
WHERE i.type = 'ACCREC'
  AND i.status = 'AUTHORISED'
  AND i.due_date < current_date
ORDER BY days_overdue DESC
LIMIT 50;

Which client files have gone stale. Worth running before anyone trusts a number:

SELECT
  o.name AS organisation,
  max(i.synced_at) AS last_synced,
  max(i.updated_date_utc) AS latest_change_in_xero
FROM xero_invoices i
JOIN xero_organisations o ON o.tenant_id = i.tenant_id
GROUP BY o.name
ORDER BY last_synced;

None of these needs a reporting product, a BI licence or a spreadsheet. They are ordinary SQL against tables you own, which also means they can feed a dashboard, a scheduled email, or your own client portal.

What to Watch For

Consolidating across organisations introduces problems that single-org syncing never shows you. These are the ones that bite.

Do not sum across currencies. Invoices carry their own currency_code, and organisations carry a base_currency. A group with a UK and an Australian entity will happily let you add pounds to Australian dollars and produce a number that means nothing. Group by currency, as the queries above do, or convert deliberately with a rate table you control.

Financial year ends differ. financial_year_end_month exists on the organisation row for exactly this reason. Two clients on different year ends cannot share a naive "this year" filter.

Demo companies pollute totals. Xero's demo organisation is real data as far as an API is concerned. The organisation row carries is_demo_company, so exclude it explicitly rather than noticing later.

Access is per organisation, and clients can revoke it. Each organisation is authorised separately, which is the correct security posture, and it also means a client offboarding removes one connection and leaves the rest untouched. Build the staleness query above and you will notice a revoked connection in a day rather than a quarter.

Rate limits apply per organisation as well as per app. Xero meters each organisation separately, with a daily cap that depends on the connecting app's Xero subscription tier, so ten organisations do not all contend for one shared bucket. It is one of the few things about Xero's API that gets easier at scale rather than harder. The specifics are in our Xero API guide.

The number that binds is rows, not clients. This is the one people get wrong when they price it up. Plans are metered on rows processed per month, and a full sync reprocesses the whole table every run. Ten organisations synced daily on full mode is a lot of repeated work. Use a fixed lookback window for scheduled runs instead, keep the window wider than the gap between runs, and reserve full syncs for the first load and the occasional reconciliation.

What It Costs

Worth doing the arithmetic before you commit, because the shape is not obvious.

Each organisation and data type pairing is one sync configuration. Ten client organisations syncing invoices, contacts and organisation details is thirty configurations, all writing into one database.

On Codeless Sync pricing, that lands on Pro at $29 a month, which allows 30 configurations across 3 database projects with a 100,000 row monthly allowance and 90 days of sync history. Starter at $19 covers 10 configurations, which suits three or four clients on a couple of data types. Business at $99 goes to 100 configurations and 10 projects, which is agency scale. The free tier allows 2 configurations and covers Xero contacts and invoices only, so it is a way to try one client, not to run a book of them, and the organisation joins above need a paid plan.

Scheduled syncing is a paid feature at every tier: daily, weekly or monthly on Starter and Pro, with a 12-hourly option on Business. For accounting data, daily is almost always the right answer.

When You Want a Reporting Tool Instead

It would be dishonest to pretend this replaces everything, so here is the line.

Products like Joiin, Fathom and Spotlight Reporting exist to produce consolidated financial statements, and they do things this approach does not: intercompany eliminations, group structures with ownership percentages, formatted board packs, budget versus actual. If what you need is a monthly group P&L that an investor will read, buy one of those.

What syncing gives you instead is the raw ledger in a database you own, queryable in SQL, joinable against everything else you hold, and available to any tool that speaks Postgres. If your reporting is bespoke, if you are building a client dashboard, or if the interesting questions cross Xero and your own systems, a reporting product cannot get you there and a database can.

The two are not really competitors. One produces statements, the other produces a data layer. Plenty of firms end up with both.

If you are still deciding whether to build the sync yourself, Xero API vs database sync works through the build-versus-buy maths, and how to export Xero data to a database covers the one-off export options.

Frequently Asked Questions

Can Xero consolidate multiple organisations natively?

No. Xero is designed around one organisation at a time, and cross-organisation consolidated reporting is a long-standing feature request Xero has not committed to. Consolidation happens outside Xero, either in a reporting product or in a database you control.

How do I tell which organisation a row came from?

By its tenant ID. Xero identifies each organisation with a tenant ID, and a well-designed destination table stores it as a column and includes it in the primary key. Sync the organisations data type as well and you can join on tenant_id to get trading names, currencies and countries instead of bare identifiers.

Do I need a separate table for each Xero organization?

No, and you should avoid it. Separate tables per organization means new tables for every client, UNION queries that need editing whenever the client list changes, and schema updates applied many times over. A composite primary key of record ID plus tenant ID lets every organisation share one table safely.

Will invoice IDs from different organisations clash?

Not if the table is keyed on both the record ID and the tenant ID. That composite key is what allows two organisations to hold records with the same identifier in the same table without overwriting each other.

How many Xero organisations can I sync?

In practice the limit is how many sync configurations your plan allows, since each organisation and data type pairing counts as one. Thirty configurations covers ten organisations across three data types. Xero also caps how many organisations can connect to any given app, and that cap sits with the app rather than with you, so if you are planning to connect a large book of clients it is worth asking us first.

Can I do the same thing with QuickBooks or Stripe?

Yes for QuickBooks. Its tables use the same composite key pattern, keyed on the record ID plus the QuickBooks company ID, so several companies share one table safely. Stripe works differently. A Stripe account is a single entity, so the tables are keyed on the record ID alone with no account column, and two Stripe accounts writing to one table would leave you unable to tell the rows apart. Give each Stripe account its own database project instead.

Wrapping Up

Multi-organisation Xero reporting looks like a Xero problem, and it is really a storage problem. Xero will keep handing you one organisation at a time, correctly, because that is what it is for. The fix is to stop asking it for a consolidated view and to keep one yourself, in a database, with a tenant ID on every row.

Once the data is there, the questions that used to take an afternoon of exports take a GROUP BY.

Try it with one client organisation and see the first table land in your own database in about five minutes.

Related:

Stripe Data Pipeline Doesn't Sync to PostgreSQL: What to Use Instead

ilshaad — Wed, 02 Sep 2026 10:55:53 +0000

You went looking for the official answer. Stripe sells a product called Data Pipeline whose entire job is getting your Stripe data out of Stripe and into somewhere you can query it, which sounds exactly like what you need. Then you open the destination list.

Snowflake. Amazon Redshift. Databricks. BigQuery. Google Cloud Storage, Azure Blob Storage, Amazon S3.

No PostgreSQL. No Supabase, no Neon, no RDS. If your stack is a Postgres database, the Data Pipeline you can actually buy today does not meet you there. The two Stripe products that will are both locked behind a preview.

This post covers what Data Pipeline actually is, what Stripe is quietly building for Postgres users and why you probably cannot have it yet, what the cloud storage route really costs if you decide to bridge the gap yourself, and the options that exist today.

What Stripe Data Pipeline Actually Is

Data Pipeline is a paid Stripe product that pushes a copy of your Stripe data to a destination you own, with no code on your side. Per Stripe's documentation, it supports two shapes of destination:

Data warehouses (Snowflake, Amazon Redshift, Databricks, BigQuery). Stripe sends a data share to your warehouse, with one instructive exception covered in the next section. Either way, your core Stripe data is available within 12 hours of setup.

Cloud storage (Google Cloud Storage, Azure Blob Storage, Amazon S3). Stripe drops Parquet files into a bucket you own.

After the initial load, both routes refresh on the same cadence: a new full load of your data every 3 hours, with Stripe noting that some tables update on their own schedules as new data becomes available. Your data is split into a STRIPE schema for live mode and a STRIPE_TESTMODE schema for sandboxes, every table carries a merchant_id column so multiple Stripe accounts can share one destination, and a data_load_times table tells you when each table was last refreshed.

Two things worth knowing that rarely make it into comparison posts. A Data Pipeline subscription includes Stripe Sigma, so you are buying the in-dashboard SQL tool along with the export. And Stripe does not offer Data Pipeline to customers in India, because of data localization requirements.

Why PostgreSQL Is Not on the List

It is tempting to read the destination list as an oversight. The setup mechanics are more interesting than that, and they explain the shape of what Stripe is building next.

Three of the four warehouse destinations arrive as a native data share, a feature of the warehouse rather than anything Stripe operates. In Snowflake you accept a share from a Stripe account and mount it as a database. In Redshift you associate an incoming datashare, which only works on an RA3 cluster with encryption enabled. In Databricks it comes through Delta Sharing and you mount the Stripe share to a catalog. No bytes move through infrastructure Stripe runs. It publishes, you accept, and your warehouse does the rest.

BigQuery is the exception. There is no share: you create a service account, grant it BigQuery Job User and BigQuery Data Editor, stand up an intermediate Cloud Storage bucket for Stripe to write to, and Stripe runs load jobs into your datasets, deleting the intermediate files afterwards.

That exception is the tell. Stripe will operate a real write pipeline into a destination you own when it decides the destination is worth the engineering. Postgres was not on the list because it is the harder version of that problem: not one managed vendor with one stable way in, but millions of instances across every host and self-run box on the internet, each with its own version, extensions, connection limits, pooler, IP allow-list and maintenance window, and no share mechanism to fall back on.

Hard is not the same as never, though, which brings us to the part most comparison posts have not caught up with.

Stripe Is Building Postgres Support, in Two Places

Neither is generally available. Neither is something you can go and buy this afternoon. Both are documented, and both are aimed squarely at the reader of this post.

Real-time sync to Postgres. Stripe's documentation for it is unambiguous: it continuously streams "your Stripe data to a Postgres database", in real time rather than in a 3-hour batch, with a schema that is "a direct mapping to the public Stripe API". Coverage is everything in the public API that has a list endpoint, so charges, customers, subscriptions, payment intents and invoices are in, while single-object resources like Balance are not, and you choose which tables to sync from the Dashboard. The setup guide is public and specific: PostgreSQL 13 or later from any provider, with Stripe naming Amazon RDS and Aurora, Supabase, Neon and self-hosted deployments; a stripe schema reserved for the pipeline; a dedicated database user that owns that schema and holds SELECT, INSERT, UPDATE and DELETE on it; an SSL connection; and sixteen Stripe IP addresses added to your firewall allowlist. Stripe then backfills the tables you picked and keeps them current. The catch is the status: it is still a preview you request access to by email, with no published general availability date, and the commitment is to "a near-real-time basis" with no end-to-end latency SLA.

Stripe Database. Announced at Sessions 2026 as a managed, hosted, read-only Postgres database holding your Stripe data, created in one click from the Dashboard or a single CLI command. Its documentation page returns a 404 unless your account is enrolled in the early access programme, so the substantive public document is the preview terms, which are worth reading before you build anything on it. It is a Preview Service "not subject to Stripe's standard compliance certifications, access controls requirements, or related auditing commitments". Stripe "may, at its discretion, temporarily throttle, rate-limit, or suspend" your access based on query volume. It "reserves the right to apply or change Fees". And on termination, "Stripe will delete all associated data".

So the honest status is that Stripe will probably solve part of this, on its own timeline. Two things stay true when it lands.

It is Stripe only. The real-time Postgres sync syncs Stripe data and Stripe Database holds Stripe data. If your reporting also needs QuickBooks, Xero or Paddle in the same database, that is a second tool or a warehouse regardless.

With Stripe Database, the data lives in Stripe's infrastructure, not yours. That is genuinely convenient, and it is also the opposite of why most people want the copy in Postgres in the first place: to join billing data against their own application tables, own the schema, and keep it somewhere they control.

Until either ships, the practical answer is unchanged. If you want Stripe data in your Postgres today, something other than Data Pipeline has to put it there.

What Data Pipeline Costs, and What the Meter Is

The pricing matters here because it shapes the decision even for people who could adopt a warehouse.

Data Pipeline is priced in tiers based on your monthly charge count, with a per-charge rate on anything above your tier. Read off Stripe's pricing page in September 2026, the entry tier covers up to 1,000 charges a month at $65 a month, or $50 a month on an annual plan, with 7 cents and 6 cents respectively per additional charge. Above that it is annual only: $75 a month up to 2,500 charges, $280 up to 10,000, $550 up to 25,000, and custom pricing beyond. The UK page shows the same ladder at £48 or £37, then £56, £209 and £410. New accounts get a 30-day free trial.

Two things sit in the small print. Monthly billing exists only on the entry tier, so passing 1,000 charges a month means taking on an annual commitment. And the meter counts "successful charges both on Stripe and through third-party payments processors in connection with any Stripe service", so payments you did not run through Stripe at all can still push you up a tier.

Note what the meter is. You are not billed for tables, rows, syncs or queries. You are billed for payment volume, which is to say your business getting busier, for a job whose difficulty does not change when it does. That is the same structural complaint as usage-priced ETL, arrived at from a different direction: Fivetran's monthly active rows model meters row churn instead, with the same result that the bill moves for reasons unrelated to what you asked for.

And this is before the destination. Snowflake, Redshift, Databricks and BigQuery all bill you separately for storage and compute. Adopting a warehouse to receive this data is not a one-line decision.

The Cloud Storage Escape Hatch, and What It Really Costs

Here is the part that a flat "Data Pipeline can't do Postgres" leaves out, and it is the honest centre of this post.

There is a technical path. Point Data Pipeline at S3, GCS or Azure Blob, and Stripe delivers Parquet files into a bucket you control. Nothing stops you writing a job that reads those files and loads them into Postgres. Stripe even helps a little: it writes a SUCCESS file per run date and mode once all files for a set of tables are transferred and validated, and it updates a /data_load_times.json file with the time and location of the most recent successful load for each table.

Now count what you own the moment you take that path.

A loader that reads Parquet. Postgres does not ingest Parquet natively. You are writing a job, in a language of your choice, on a runtime you have to host, or standing up something like DuckDB or a Spark step in between.
Type mapping. Parquet's types are not Postgres types. Timestamps, nested structures, numeric precision and the JSON-shaped fields in Stripe's schema each need a decision, and the wrong one is usually discovered months later inside a report. Our post on designing a Postgres schema for Stripe data covers the choices that bite.
Deduplication, every three hours, forever. This is the big one. Each run is a full load, not a changelog. You are handed the whole dataset again eight times a day, and it is entirely on you to turn that into idempotent upserts against your existing rows rather than duplicates. Get the conflict target wrong once and you are cleaning up a table by hand.
Orchestration and failure handling. Polling for the SUCCESS file, not starting on a half-written batch, retrying, and alerting when a load silently stops.
Schema drift. Stripe adds fields. Your loader has to notice, and your table has to change.
Two bills. You are paying Stripe for Data Pipeline, and paying for the bucket, the egress and whatever compute runs the loader.

None of this is hard in the sense of being intellectually difficult. It is hard in the sense of never being finished. You wanted Stripe data in a table; you have acquired a data pipeline, and pipelines are things people end up on call for. If the appeal of Data Pipeline was "without writing code", the cloud storage route quietly hands the code back.

Today's Version Is Not Real Time

One more expectation worth resetting before you build anything around this.

A 3-hour cadence is not a 3-hour freshness guarantee. Stripe's data freshness documentation works the example: with a 3-hour cadence, a record created at 00:01 UTC is picked up in the 03:00 UTC batch, and with a typical delivery time of about three hours after the batch closes, it lands by 06:00 UTC. That is a P50 freshness of six hours from event creation. Half the time it is slower than that, delivery varies with your data volume, and derived datasets run on their own schedules.

That is completely fine for finance, reporting and analytics, which is what the product is for. It is not fine if you were planning to drive product behaviour off the copy. Real-time streaming is exactly what the Postgres sync in preview promises, which is Stripe's own way of conceding that the shipping product does not do it. Until that is generally available, if you need a customer's subscription state correct within seconds, that is a webhook job rather than a sync job. We covered where the line sits in how often you should sync billing data to Postgres.

Your Real Options for Getting Stripe Data into Postgres Today

Assuming Postgres is not negotiable, these are the paths, with the trade-off named honestly.

Option	What it costs you	Best when
Wait for Stripe's real-time Postgres sync	No money, but no date either, and access is Stripe's decision	Stripe is your only source and the timing genuinely does not matter
Adopt a warehouse	Warehouse bill plus a Data Pipeline tier, and a second system to run	You already run Snowflake, BigQuery, Redshift or Databricks
Cloud storage plus your own loader	Data Pipeline tier, storage, compute, and permanent ownership of the job	You have a data engineer and Parquet is already in your stack
Stripe API plus your own script	Build time, pagination, rate limits, retries, schema upkeep	Your needs are narrow enough that nothing off the shelf fits
Managed sync straight into Postgres	A flat subscription, and a narrower feature set than a warehouse platform	Postgres is the destination and you want the job to be finished

If you want the full field rather than these four, 5 ways to get Stripe data into PostgreSQL walks the methods, and the best tools to sync Stripe data to a database reviews seven products with their weak points included.

When Data Pipeline Is Still the Right Call

It would be a bad post that only argued one way, so here is the case for buying it.

If a warehouse is already in your stack, Data Pipeline is close to unbeatable for Stripe specifically. It is first-party, and Stripe's pitch is that you get "structured and ready-to-use datasets not available through third-party APIs or ETLs", which nothing built on the public API can match. On the three share-based destinations there is no pipeline to run at all. Multi-account businesses can fold every Stripe account into one destination and filter on merchant_id, and Organizations gives administrators a single view of every pipeline. Sigma is bundled rather than sold separately, so the reporting layer arrives with it, which we compared in the best Stripe Sigma alternative for Postgres users.

Two limits to know before committing: you can connect only one warehouse account to a Stripe account at a time, and the pre-built financial report templates are Snowflake only, not available on Redshift, Databricks or BigQuery.

The question is not whether it is a good product. It is whether you are willing to run a warehouse in order to use it.

The Postgres-Native Version

If your destination is Postgres and you want the job to stay finished, that is the narrow problem Codeless Sync exists for.

You connect Stripe with a restricted, read-only API key, choose a data type, and the destination table is created for you in your own database. It works with Supabase, Neon, AWS RDS, Railway, DigitalOcean and any other Postgres you can reach, and the same setup covers QuickBooks, Xero and Paddle if your billing data is not all in one place. The first sync takes about five minutes.

The difference from the cloud storage route is not the setup, it is the ownership. There is no Parquet reader, no type mapping, no dedupe logic, no SUCCESS file to poll, no schema drift to chase. Syncs upsert on the record's Stripe ID, so a re-run corrects rather than duplicates, and rate limits, retries and pagination are ours to worry about.

The pricing is a flat monthly fee rather than a meter on your payment volume. Free is $0 for 2 manual syncs a day, 2 configurations and one database project. Starter is $19 a month, Pro is $29 and Business is $99, each adding configurations and a larger monthly row allowance, with more database projects from Pro upwards. Scheduled syncs are the paid feature: Starter and Pro run daily, weekly or monthly, and Business adds a 12-hourly option.

Put the two next to each other on the axes that actually differ:

	Stripe Data Pipeline	Codeless Sync
PostgreSQL	Not a destination	The only destination
Priced on	Your monthly charge count	Flat monthly fee
Second system needed	A warehouse, or a bucket plus a loader you build	No
Cadence	Full load every 3 hours, P50 about 6 hours old	Manual, or scheduled daily to monthly, 12-hourly on Business
Sources	Stripe	Stripe, QuickBooks, Xero, Paddle
Dataset coverage	First-party, includes data the API does not expose	Common billing tables
Bundled reporting	Includes Sigma	No, you query your own Postgres

Data Pipeline wins coverage and completeness. It cannot win a single row of that table that involves the word Postgres, and that is the row you came here for.

Frequently Asked Questions

Does Stripe Data Pipeline support PostgreSQL?

No. Data Pipeline delivers to Snowflake, Amazon Redshift, Databricks and BigQuery, or to Google Cloud Storage, Azure Blob Storage and Amazon S3. PostgreSQL, including Supabase, Neon and AWS RDS, is not a supported destination.

Is Stripe adding PostgreSQL support to Data Pipeline?

Yes, through a real-time sync to Postgres that is still in preview. Stripe's documentation describes it as continuously streaming Stripe data to a Postgres database, with a schema mapped directly to the public API, and the setup guide is already public: PostgreSQL 13 or later from any provider including RDS, Supabase and Neon, a reserved stripe schema, a dedicated database user, SSL, and sixteen Stripe IP addresses allowlisted on your firewall. You request access by email, and there is no published general availability date.

What is Stripe Database?

A managed, hosted, read-only Postgres database of your Stripe data, announced at Sessions 2026 and still in preview, with documentation gated behind early access enrolment. Note that the data sits in Stripe's infrastructure rather than your own, so you cannot join it against your application tables, and the public preview terms let Stripe throttle access, change fees, and delete all associated data on termination.

Can I get Stripe Data Pipeline into Supabase or Neon?

Not directly. The nearest path is exporting Parquet files to cloud storage and writing your own job to load them into your database, which means owning a loader, type mapping, three-hourly deduplication and schema drift. A managed Stripe to Postgres sync does the same job without the pipeline.

How much does Stripe Data Pipeline cost?

It is tiered on your monthly charge count, with a per-charge rate above each tier. Checked in September 2026, the entry tier covers up to 1,000 charges a month at $65 a month, or $50 a month on an annual plan, and the tiers above it are annual only at $75, $280 and $550 a month for 2,500, 10,000 and 25,000 charges. Warehouse storage and compute are billed separately by your warehouse provider.

How fresh is Stripe Data Pipeline data?

Stripe delivers a full load every 3 hours. Because a record waits for the next batch and then for delivery, Stripe's own worked example comes to a P50 freshness of about six hours from event creation, with delivery time varying by data volume.

Is Stripe Data Pipeline the same as Stripe Sigma?

No, though a Data Pipeline subscription includes Sigma. Sigma runs SQL inside the Stripe Dashboard and returns results there. Data Pipeline copies your data to an external destination you own.

What is the fastest way to get Stripe data into a Postgres database?

A managed sync. Connecting a read-only Stripe key and letting the tool create the destination table takes about five minutes, against the days it takes to build a Parquet loader or a paginated API script, and it keeps working afterwards.

Wrapping Up

Stripe Data Pipeline is a good product aimed at a reader who is not you. It assumes a warehouse, it prices on payment volume, and its Postgres story today is a bucket of Parquet files plus a job you write yourself. The version with a real Postgres destination exists, and it is in preview with no date, which is not something you can plan a quarter around.

If Postgres is where your data lives, skip the detour. Either adopt a warehouse deliberately, for reasons that go beyond this one export, or use something built to land Stripe data in Postgres and be done with it.

Start a free sync and see your Stripe tables in your own database in about five minutes.

How Often Should You Sync Billing Data to Postgres?

ilshaad — Mon, 24 Aug 2026 07:28:28 +0000

Daily, twice daily, weekly or monthly. How to pick a sync schedule for Stripe, QuickBooks, Xero or Paddle data, and why real-time is usually the wrong goal.

By Ilshaad Kheerdali · 24 August 2026

You have your billing data landing in Postgres. The connection works, the table is there, the first sync completed. Now there is a dropdown asking how often you want to repeat it, and no obvious way to answer.

The instinct is to pick the fastest option available, on the reasoning that fresher is better and the sync is automated anyway. That instinct is worth resisting. For billing data specifically, the right cadence is usually slower than people expect, and picking a faster one costs you in places that are not obvious on day one.

This post covers how to choose, how to match the sync mode to the schedule you picked, and the one case where scheduling is genuinely the wrong tool.

Start With the Decision, Not the Data

The useful question is not "how fresh could this be". It is "what decision am I making with it, and how often do I make that decision".

Billing data is consumed in a small number of recognisable ways, and almost all of them are periodic:

Board reporting and investor updates. Monthly, occasionally quarterly. The numbers are cut at a month boundary and nothing that happens on a Tuesday afternoon changes them.
MRR, churn and cohort dashboards. Reviewed weekly by most teams, daily by some. The underlying figures move slowly enough that hourly refreshes show noise, not signal.
Month-end reconciliation. Intense for a few days, irrelevant for the rest of the month. Daily is comfortably enough, because the work happens against a closed period.
Customer support lookups. Feels like it needs to be live, usually is not. Support agents overwhelmingly need "what plan is this person on and did their last invoice clear", which a daily copy answers correctly for the vast majority of tickets.
Dunning and failed payment follow-up. The most time-sensitive of the common cases, and the one worth syncing twice a day for if you act on it manually.

If your use case is on that list, daily is the default answer and you should need a reason to move away from it. Weekly is right more often than people admit, particularly for accounting data from QuickBooks or Xero where the source system is itself updated in batches by a human.

What Actually Changes, and How Fast

The other half of the answer is how much your data really moves, which is usually less than it feels.

Customer records are close to static. A row changes when someone updates a card, an email or a billing address. For most SaaS businesses that is a low single-digit percentage of the table per month.

Subscriptions move more than they look like they do, because every status transition is a write: trialing to active, active to past_due, past_due to canceled, plus plan changes, quantity changes and renewals. Still, an individual subscription generates a handful of changes a year, not a day.

Invoices and charges are the genuinely busy tables, and they are lifecycle-heavy. An invoice moves through draft, open and paid, with a possible detour through a failed payment and a retry. But they are also the most predictable: they are created on billing anniversaries and settle within days.

Accounting data behaves differently again. QuickBooks and Xero records change when a person enters them, which means they arrive in bursts around invoicing runs and month end, and are quiet in between. Syncing a Xero ledger every hour mostly re-reads a ledger nobody has touched since yesterday.

The pattern across all four providers is the same: billing data changes in bursts tied to billing cycles and human work rhythms, not continuously. A schedule that matches those rhythms captures nearly everything a faster schedule would, at a fraction of the cost.

The Costs of Syncing Too Often

Faster schedules are not free, and the bill arrives in four places.

Your provider's rate limits. Stripe's published limits are 100 requests per second in live mode and 25 per second for an individual endpoint, which sounds like plenty. The constraint that actually bites is quieter: Stripe allocates read requests relative to your transaction count, at "an average of 500 per transaction" over a rolling 30 days, with a floor of 10,000 read requests per month. A business processing 100 transactions a month has a 50,000 read allocation, and a paginated full sync of several tables can consume a meaningful slice of that in a single run. Multiply by 24 runs a day and the arithmetic stops working. Xero is stricter still, with a per-tenant daily cap that starts at 1,000 calls a day on its entry tier. QuickBooks and Paddle both enforce their own per-minute limits.

Sync duration and overlap. Every run has fixed overhead: authenticating, paginating, comparing rows, writing. Schedule runs closer together than a run takes to finish and you get overlapping jobs competing for the same table, which is a good way to turn a working pipeline into an intermittent one.

Your own quota. Every managed sync tool meters something. Runs that produce no changes still consume your daily sync allowance, so an aggressive schedule spends your plan on re-reading unchanged rows.

Database write amplification. Frequent full syncs rewrite rows that did not change, which inflates your Postgres write volume and, on serverless hosts that bill on compute time, your database bill too.

None of these are catastrophic individually. Together they mean an hourly schedule on data that changes daily is pure waste.

Matching the Sync Mode to the Schedule

This is the part that most often goes wrong, and it matters more than the frequency itself.

A scheduled sync has two settings, not one: how often it runs, and how much data each run fetches. In Codeless Sync, a full sync is the default and re-reads everything in the table. The alternatives are fixed lookback windows: the last day, the last 7 days, or the last 30 days. These are windows, not a bookmark. A "last 7 days" run always asks for the last 7 days of changes, regardless of when the previous run happened or whether it succeeded.

That single detail drives the rule:

Your lookback window must be wider than the gap between runs. If they are equal, one failed or delayed run leaves a permanent hole in your data.

A daily schedule paired with a last-day window has zero margin. The run that fails at 2am on a Sunday silently loses Saturday's changes, and nothing later goes back for them. Pair a daily schedule with a last-7-days window instead and you get six days of self-healing overlap for almost no extra cost, because re-fetching a mostly-unchanged week is cheap.

Sensible pairings:

Schedule	Lookback window	Why
Twice daily	Last 7 days	Wide safety margin, still a small fetch
Daily	Last 7 days	Six days of overlap absorbs failed or skipped runs
Weekly	Last 30 days	Covers a missed week and late-arriving edits
Monthly	Full sync	Volume is low enough that correctness beats efficiency
Any, small table	Full sync	Under a few thousand rows, just re-read it and stop thinking

Full sync deserves more credit than it usually gets. It is the only mode that reliably reflects deletions and corrections made to historical records, which accounting systems produce constantly when someone amends last quarter's invoice. If your tables are small, full sync on a daily schedule is the most robust configuration available and the reason it is the default.

When Scheduling Is the Wrong Tool

There is a case where no schedule is correct, and it is worth naming plainly so you do not try to solve it with frequency.

If you need to react to an individual billing event within seconds, provisioning access the moment a payment clears, or emailing a customer the instant a card fails, that is not a reporting problem and a sync will not solve it at any cadence. Even a one-minute schedule gives you an average latency of thirty seconds and a worst case of sixty, with no ordering guarantees. Use the provider's webhooks for that specific workflow: they exist precisely for event-driven reactions, and they push in real time.

The mistake is assuming that because you need webhooks for one workflow, you need them for everything. Webhooks are excellent at "tell me when this one thing happens" and poor at "give me a complete, queryable table I can run SQL against", because they deliver events rather than state, they can be missed, and they never cover history. A scheduled sync is the opposite on all three counts.

Most teams end up wanting both, and that is a reasonable architecture: webhooks for the two or three events that trigger immediate action, a scheduled sync for the tables you query. We covered the trade-off in detail for Stripe and for Paddle.

Setting It Up

In Codeless Sync, scheduling lives on the configuration you already created. You pick a frequency, pick a sync mode, and the schedule runs without further involvement. Daily, weekly and monthly are available on every paid plan, and twice daily is available on Business. Free accounts sync manually.

Two practical notes. First, schedules are evaluated against a fixed time, so choose an hour that suits your reporting rather than leaving everything at midnight UTC, especially if your finance team works to a local month end. Second, a schedule only runs when the project, the configuration and the schedule itself are all active, so if runs stop appearing, check all three before assuming a failure.

The schedules documentation covers the mechanics, and how to use cron expressions for scheduled data syncs explains the syntax behind the presets. If you have not connected a database yet, the quick start takes about five minutes.

A Reasonable Default

If you want to stop reading and just pick something:

Daily, with a last-7-days window, at an hour that suits your reporting. Move to twice daily only if you act on dunning manually. Move to weekly if your data is accounting-led and entered by hand. Switch to full sync if your tables are small or your source system amends historical records.

You can change it later. That is rather the point of not agonising over it now.

Frequently Asked Questions

How often should I sync Stripe data to Postgres?

Daily suits almost every reporting, dashboard and reconciliation use case. Twice daily is worth it if you manually work failed payments. Faster than that rarely changes a decision, and it consumes your Stripe read allocation, which is capped relative to your transaction volume rather than being unlimited.

Is real-time syncing better?

Not for billing data. Real-time is better for reacting to individual events, which is a webhook's job. For a queryable table you run SQL against, a scheduled sync gives you completeness and history, which matter more than latency for reporting.

What happens if a scheduled sync fails?

The next scheduled run goes ahead as normal. Because lookback windows are fixed rather than resuming from a bookmark, a failed run is only self-correcting if your window is wider than your schedule interval. A daily schedule with a last-7-days window recovers automatically. A daily schedule with a last-day window does not.

Should I use full sync or an incremental window?

Full sync if your tables are small, or if your source system amends historical records, since it is the mode that reflects deletions and corrections. An incremental window once the table is large enough that re-reading it every run is wasteful. Full sync is the default for that reason.

Does syncing more often cost more?

The subscription price does not change, but each run counts against your daily sync allowance, and every provider enforces API rate limits. Frequent full syncs also increase Postgres write volume, which can matter on hosts that bill by compute time.

Can I sync different tables on different schedules?

Yes. Scheduling is set per configuration, so you can run invoices daily and customers weekly by creating separate configurations. This is usually a better use of your sync allowance than putting everything on the fastest schedule.

Wrapping Up

The honest answer to "how often should I sync" is "less often than you first assumed, with a wider lookback window than you first assumed".

Billing data moves in bursts tied to billing cycles, and the decisions you make with it are periodic. Matching your schedule to those rhythms, and leaving enough overlap that a failed run heals itself, gets you a more reliable pipeline than chasing freshness ever will.

See the pricing page for which schedules come with which plan, or start on the free tier and sync manually until you know what cadence you actually need.

Related:

Fivetran Pricing Explained: Why MAR Billing Is Overkill for One Billing Sync

ilshaad — Mon, 17 Aug 2026 08:14:09 +0000

Fivetran prices on monthly active rows. Here is how MAR actually works, what changed in January 2026, and why the bill is hard to forecast for one sync.

By Ilshaad Kheerdali · 17 August 2026

You have one billing source, Stripe or QuickBooks or Xero or Paddle, and one Postgres database. You want the first to land in the second on a schedule. Somewhere in the research you end up on Fivetran, and the pricing page quotes you in a unit you have never used before: monthly active rows.

MAR is not a bad idea. It is a genuinely fairer meter than per-connector seat pricing for a company moving hundreds of tables. The problem for a reader in your position is narrower and worth naming precisely: MAR is priced on how much your data changes, and you cannot know that number before you start.

This post explains how MAR works, what changed on 1 January 2026, and where the model stops making sense for a single billing source.

What a Monthly Active Row Actually Is

A monthly active row is a distinct row that was inserted, updated or deleted in a calendar month, identified by its primary key.

The part people get wrong is the counting. From Fivetran's own documentation: "We only count a row once per month, even if it syncs multiple times." A subscription record that changes thirty times in March is one MAR, not thirty. That is the model working in your favour, and it is why running syncs more often does not directly cost more.

Two details matter more than the headline:

MAR is measured per connection, not per account. Since March 2025, Fivetran calculates usage separately for each account, destination, connection and table. Syncing the same Stripe data to two destinations counts twice.
Rows that did not change are free. Only churn is billable, which is why a table with a million static rows can cost almost nothing while a small, busy table costs more.

What Changed on 1 January 2026

Three things moved, and older comparison posts have not caught up.

Deletes now count toward paid MAR. Fivetran's 2026 pricing update states it plainly: "As of January 1, 2026, inserts, updates, and deletes will count toward paid MAR. Previously, deletes did not contribute to paid MAR." The reasoning is defensible, since a deletion is a real change with analytical value, but it is a straightforward increase for any source that removes records.

There is now a minimum charge per connection. A $5 base charge applies to every standard connection doing between 1 and 1 million MAR per month. If you have five small connections that barely move, you now have a $25 floor before any usage is counted. The Free plan is exempt.

The Starter and Private Deployment plans are gone. The current lineup is Free, Standard, Enterprise and Business Critical, the last of which adds customer-managed encryption keys, PCI DSS Level 1 and private networking.

Yes, the Free Plan Is Real

Most posts arguing against Fivetran skip this, and skipping it makes the argument worse rather than better.

Fivetran's Free plan includes 500,000 MAR per month, along with 3,500 activation MAR and 5,000 transformation model runs. It is a plan, not a trial. There is also a 14-day account trial, and separately each new connection gets 14 days of free use starting when incremental syncs are first detected.

For a single billing source at small scale, 500,000 changed rows in a month is a lot of headroom. A SaaS business with a few thousand customers and a few thousand invoices a month will not come close. If that is you, Fivetran may well cost you nothing, and any post telling you it is too expensive is selling you something.

So the honest question is not "is Fivetran expensive". It is "what happens after that, and can you see it coming".

Why the Bill Is Hard to Forecast

Here is the part that should decide it for a one-source setup.

There is no published per-MAR rate. Fivetran's pricing page describes a consumption curve where the per-row cost falls as volume rises, and points you to a Service Consumption Table and a pricing estimator. Neither renders a plain rate card you can read, quote or put in a spreadsheet. I went looking specifically to include real numbers here and could not verify a single per-MAR figure from Fivetran directly.

Third-party sites fill the gap badly. In the course of writing this I found published claims of $500 per million MAR and $2.50 per million MAR for the same Standard plan. Those differ by a factor of two hundred. At least one is wrong, possibly both, and there is no authoritative document to settle it. If you see a confident per-row number in a comparison post, treat it as a guess.

The meter tracks your customers' behaviour, not your requirements. This is the structural issue. Your infrastructure needs are flat: one Stripe account, a handful of tables, a nightly refresh. Your MAR is driven by how many subscriptions changed state, how many invoices moved from open to paid, how many records were removed. A billing month with a promotion, a price migration, a dunning wave or a bulk cleanup produces a bigger invoice than a quiet month, for the same pipeline doing the same job.

Cost arrives as a step, not a slope. Below 500,000 MAR you pay nothing. Above it you are on a paid plan with a $5 per-connection floor and a rate you had to run an estimator to discover. Nothing warns you as you approach the line, and the crossing is caused by your customers, not by a decision you made.

For a data team running fifteen sources into Snowflake, forecasting that is a normal part of the job and the volume discounts are worth having. For one billing sync into Postgres, you have taken on a variable cost and a modelling exercise to solve a fixed problem.

What Actually Drives MAR on a Billing Sync

It helps to see where the churn comes from, because it is rarely the table you expect.

Customers are the calmest table. A customer record changes when someone updates a card, an address or an email, so a few percent of the table per month is typical.

Subscriptions are busier than they look. Every status transition is an update: trialing to active, active to past_due, past_due to canceled, plus renewals, plan changes and quantity changes. A subscription can produce several distinct active months per year even when the customer does nothing unusual.

Invoices and charges are the volume driver, and they are lifecycle-heavy. A single invoice moves through draft, open, paid, and possibly through a failed payment and a retry. Because MAR counts a row once per month regardless of how many of those transitions happen, this is much better than it sounds, but the row count still scales directly with your transaction volume.

The rough shape: your monthly MAR is closer to "customers who did something" plus "invoices raised this month" than to the total size of your Stripe account. That is the number to estimate before signing anything, and it is also the number that moves without warning.

One thing that does not cost you: historical syncs are free. Fivetran's documentation confirms that initial syncs do not incur a charge for the historical data they load, and that tracked incremental updates are what may count outside a connection's free trial period. Backfilling five years of Stripe history is not what puts you over the line. Ordinary month-to-month operation is.

When Fivetran Is the Right Call

It would be dishonest to write this without the other side, so here it is.

Fivetran is a serious product and MAR is a serious pricing model. Choose it when you have many sources rather than one, when the destination is a warehouse like Snowflake, BigQuery, Redshift or Databricks, when you need 700+ connectors covering systems nobody else supports, or when you need the compliance posture in the Business Critical tier. At real volume the consumption curve works for you, since the per-row cost falls as usage rises, and an annual commitment takes up to 22% off.

If you are building a central analytics platform, the flexibility is worth the forecasting work.

When It Is Overkill

One billing provider. One Postgres database. A handful of tables. A once- or twice-daily refresh.

That workload has no need for 700 connectors, no warehouse, no transformation layer, and no reason to be metered on row churn. You are buying a platform to solve a problem that is closer to a scheduled copy, and paying for it in a unit that varies with your customers' behaviour.

What you want instead is a flat number you can put in a budget and forget.

The Flat-Fee Version

Codeless Sync does the narrow version of this job: Stripe, QuickBooks, Xero and Paddle into PostgreSQL, including Supabase, Neon, AWS RDS, Railway and DigitalOcean. You connect the provider, pick a data type, and the destination table is created for you.

The pricing is a short list of fixed numbers you can read before you sign up. Free is $0 for 2 manual syncs a day, 2 configurations and 1 database project. Paid tiers start at $19 a month for Starter, $29 for Pro and $99 for Business, and each adds scheduled syncs, more configurations and a larger monthly row allowance.

Every tier does include a monthly row allowance, so volume is not irrelevant. The difference is what happens at the boundary: an allowance is a ceiling you can read on the pricing page before you commit, not a meter that turns a busy billing month into a larger invoice. You can outgrow a plan. You cannot be surprised by one.

Scheduled syncs are the paid feature, and when you create a schedule you choose the sync mode. A full sync is the default and re-reads everything, or you can pick a fixed window that fetches records changed in the last day, 7 days or 30 days. Keep the window wider than the gap between runs, so a daily schedule pairs best with the last-7-days window and a failed run heals itself on the next one. Cron expressions for scheduled data syncs covers the syntax if you want a specific cadence.

Side by side, on the axes that actually differ:

	Fivetran Standard	Codeless Sync
Pricing unit	Monthly active rows, per connection	Flat monthly fee
Published rate you can quote	No, estimator only	Yes, $19 to $99 a month
Same bill every month	No, tracks row churn	Yes
Sources	700+	Stripe, QuickBooks, Xero, Paddle
Destinations	Warehouses, databases, 200+ targets	PostgreSQL
Free tier	500,000 MAR per month	2 syncs per day, no card
Best for	Many sources into a warehouse	One or two billing sources into Postgres

Fivetran wins the top half of that table and it is not close. The question is whether you need any of it.

If you want the wider field rather than a straight comparison, the best tools to sync Stripe data to a database covers seven options with honest trade-offs, and the best Stripe Sigma alternative for Postgres users covers the reporting angle specifically.

Frequently Asked Questions

What is a monthly active row in Fivetran?

A distinct row, identified by primary key, that was inserted, updated or deleted during a calendar month. It is counted once per month no matter how many times it syncs, and it is measured separately for each connection, destination and table.

Is Fivetran free for a small Stripe sync?

It can be. The Free plan includes 500,000 MAR per month, which is more changed rows than most small SaaS businesses generate. The catch is that nothing tells you how close you are getting, and crossing the line puts you on a paid plan with a rate you have to run an estimator to find.

Did Fivetran's pricing change in 2026?

Yes, on 1 January 2026. Deletes now count toward paid MAR where previously they did not, and a $5 minimum charge now applies to standard connections doing between 1 and 1 million MAR per month. The Starter and Private Deployment plans were also discontinued.

Why can't I find Fivetran's price per row?

Because it is not published as a flat rate. The per-MAR cost follows a consumption curve that falls as volume rises, and Fivetran directs you to a pricing estimator rather than a rate card. Per-row figures quoted on comparison sites are unreliable, and I found published claims differing by a factor of two hundred for the same plan.

Does a historical backfill count toward my MAR?

No. Fivetran's documentation states that initial syncs do not incur a cost for the historical data they load. It is the ongoing incremental updates that count, so loading years of Stripe history is not what pushes you over a threshold.

What is a cheaper alternative for one billing source?

If your requirement is one or two billing providers into PostgreSQL, a flat-fee tool is both cheaper and easier to budget. Codeless Sync is $0 for manual syncs, and scheduled syncs start at $19 a month, with the same bill regardless of how many rows changed.

Wrapping Up

MAR is a reasonable answer to a question you probably are not asking. It exists so that a company moving thousands of tables pays in proportion to the work done, and it does that job well.

For one billing source going into one Postgres database, it converts a fixed requirement into a variable cost, prices it in a unit you cannot look up, and hands you a threshold your customers control. Fivetran's free tier may cover you today. The thing worth weighing is what happens the month it does not, and whether you would rather just know the number.

Try the flat-fee version at codelesssync.com

Related:

How to Sync Billing Data to DigitalOcean Managed PostgreSQL

ilshaad — Mon, 10 Aug 2026 13:31:08 +0000

Sync Stripe, QuickBooks, Xero or Paddle into DigitalOcean Managed PostgreSQL. Flat monthly database pricing, no ETL bill that grows with your row count.

By Ilshaad Kheerdali · 10 August 2026

Most guides about getting billing data into Postgres skip the part people actually care about, which is what the bill looks like at the end of the month. You can build a perfectly good pipeline and still be unpleasantly surprised, because the database is priced per hour, the pipeline is priced per row, and neither number is knowable in advance.

DigitalOcean Managed PostgreSQL is a good answer to half of that problem. It has a flat monthly price with a small, published list of tiers, and you know what you owe before you start. This guide covers the other half: getting Stripe, QuickBooks, Xero or Paddle data into it without adding a variable-cost pipeline on top.

Why DigitalOcean for Billing Data

Billing data has an unusual shape. It is small (most SaaS companies are talking about thousands of rows, not millions), it changes slowly, and it gets queried constantly because it sits behind every revenue question anyone asks. That profile is a poor fit for infrastructure priced on throughput and a good fit for a fixed monthly box.

Here is what DigitalOcean actually charges for Managed PostgreSQL:

RAM	vCPUs	Storage	Monthly
1 GiB	1	10-30 GiB	$15.15
2 GiB	1	30-60 GiB	$30.45
4 GiB	2	60-120 GiB	$60.90
8 GiB	4	140-280 GiB	$122.10
16 GiB	6	290-580 GiB	$244.35

Extra storage beyond the base allocation is $0.215 per GiB per month.

The detail worth knowing, and the one most comparison posts miss: traffic to and from DigitalOcean managed databases does not count against your bandwidth transfer allowance. That is DigitalOcean's own wording, not an inference. For a workload that repeatedly pulls data in on a schedule, that removes an entire category of surprise line item. It is one of the few places where a sync workload is genuinely cheaper to run than the marketing implies.

What you give up compared to AWS RDS is the deep ecosystem: no IAM database authentication, fewer regions, no Aurora-style scaling story. For a billing table that nobody is sharding, none of that matters. If you are already on RDS and want that route instead, we covered it in syncing billing data to AWS RDS.

The DigitalOcean Connection String Gotcha

This is where most first attempts fail, and it has nothing to do with your billing provider.

DigitalOcean does not use port 5432. It issues exactly two ports, and picking the wrong one produces a confusing failure rather than a clear error:

25060 is the direct connection to the database
25061 is the connection pool, if you have created one

A DigitalOcean connection string looks like this:

postgresql://doadmin:password@db-postgresql-lon1-12345-do-user-123456-0.k.db.ondigitalocean.com:25060/defaultdb?sslmode=require

Three things to get right:

The port. If you created a connection pool and paste the pool's credentials with port 25060, or the direct credentials with 25061, the connection fails in a way that reads like a password problem. Copy the whole string from the DigitalOcean control panel rather than assembling it by hand.
sslmode=require. DigitalOcean enforces SSL. The parameter is already in the string the control panel gives you, so the usual cause of losing it is retyping the string or trimming query parameters.
Trusted sources. Under your database cluster's Network Access tab, DigitalOcean lets you restrict inbound connections to specific Droplets, Kubernetes clusters, App Platform apps, IP addresses or tags. If you have added any trusted sources, an external service cannot reach the database until it is allowed too, so check this tab first when a connection test fails for no obvious reason.

If a connection string is not behaving and you would rather not guess, paste it into our free PostgreSQL connection string validator. It parses the host, flags whether you are on a direct or pooled port, and tells you what is missing. It handles DigitalOcean's ports specifically.

Connecting Your Billing Provider

Once the database is reachable, the rest is short. In Codeless Sync, create a sync configuration, pick Digital Ocean as the database platform, and paste the connection string. It is validated before you continue, so you find out immediately if the port or SSL parameter is wrong.

Then authorize the provider you want to pull from:

Stripe and Paddle use an API key. For Stripe, use a restricted key with read-only permissions rather than your secret key.
QuickBooks and Xero use OAuth, so you approve access on their consent screen and never handle a token yourself.

Choose a data type (Customers is the easiest to eyeball first), let the destination table be created automatically, and run the sync. The full walkthrough with screenshots lives in the quick start guide if you want it step by step.

The table naming is predictable: stripe_customers, quickbooks_invoices, xero_contacts, paddle_subscriptions, and so on. Each provider gets its own tables, so you can run several providers into one cluster without them colliding.

Will It Fit on the $15 Plan?

This is the question the pricing table does not answer, and it is worth two minutes before you commit.

The entry tier gives you 10 GiB of storage. Billing tables are mostly short text fields, timestamps and numerics, plus a JSONB column holding the original API object. That JSONB column is the one that actually consumes space, because it stores the complete record rather than the handful of columns you query.

After your first sync, ask Postgres directly:

SELECT
  relname AS table_name,
  to_char(n_live_tup, 'FM999,999,999') AS approx_rows,
  pg_size_pretty(pg_total_relation_size(relid)) AS total_size
FROM pg_catalog.pg_stat_user_tables
WHERE relname LIKE 'stripe\_%'
   OR relname LIKE 'quickbooks\_%'
   OR relname LIKE 'xero\_%'
   OR relname LIKE 'paddle\_%'
ORDER BY pg_total_relation_size(relid) DESC;

One caveat: n_live_tup is an estimate maintained by autovacuum, so straight after a first sync it can still read zero. Run ANALYZE; first if the row counts look wrong. The size column is always accurate.

To turn that into a forecast, work out the space per thousand rows and multiply by where you expect to be in a year:

SELECT
  pg_size_pretty(SUM(pg_total_relation_size(relid))) AS billing_data_total,
  pg_size_pretty(
    SUM(pg_total_relation_size(relid)) / NULLIF(SUM(n_live_tup), 0) * 1000
  ) AS per_1k_rows
FROM pg_catalog.pg_stat_user_tables
WHERE relname LIKE 'stripe\_%'
   OR relname LIKE 'quickbooks\_%'
   OR relname LIKE 'xero\_%'
   OR relname LIKE 'paddle\_%';

For most small and mid-sized SaaS businesses the answer comes back in tens or low hundreds of megabytes, which means the 10 GiB entry tier is not the constraint and will not be for years. Where the entry tier does bite is RAM: 1 GiB is fine for a billing table you query a few times a minute, and tight if this cluster is also serving your application. If billing data is sharing a database with production traffic, start at 2 GiB.

What This Actually Costs End to End

Putting the two halves together, for a single small billing sync:

	Monthly
DigitalOcean Managed PostgreSQL, entry tier	$15.15
Codeless Sync Free (manual syncs, 2 per day)	$0
Total, manual	$15.15
Codeless Sync Pro (scheduled syncs, 40 per day)	$29
Total, scheduled and hands-off	$44.15

Both numbers are the same every month regardless of how many rows move, which is the whole point. Usage-priced ETL tools bill on rows changed, so your invoice tracks your growth in a way you cannot forecast at the start of the month, and a busy billing month costs more precisely when you are least inclined to audit it.

To be fair to the alternatives: if you are syncing one small provider and stay inside a generous free tier, a usage-priced tool can be cheaper than $29. The trade is predictability, and it flips as soon as you add a second or third provider, because per-connector pricing means each one is metered separately.

Keeping It Current

A one-off sync is enough to explore. For anything you actually depend on, put it on a schedule so nobody has to remember it.

Scheduled syncs are a paid feature. When you create a schedule you also pick the sync mode: a full sync, which is the default and re-reads everything, or an incremental window that fetches only records changed in the last minute, day, 7 days or 30 days. Matching the window to the cadence is what keeps each run short and keeps load on a 1 GiB cluster negligible, so a daily schedule pairs naturally with the last-day window.

Different providers can run at different cadences. Stripe customers hourly and QuickBooks invoices daily is a reasonable default, since invoices genuinely do not change often enough to justify hourly polling. If you want help choosing, cron expressions for scheduled data syncs covers the syntax.

Frequently Asked Questions

Does Codeless Sync work with DigitalOcean's connection pool?

Yes. Both the direct port (25060) and the pool port (25061) work. Use whichever the control panel gives you, and make sure the port matches the credentials, since pool and direct connections have separate ones.

Do I need to add Codeless Sync to my trusted sources?

If you have added trusted sources to the cluster, yes. Trusted sources live under the Network Access tab and act as a firewall, so any source not on the list is refused. If you have never touched that tab, there is nothing to add. It is the first place to look when the connection test fails but the connection string is definitely correct.

Will syncing count against my DigitalOcean bandwidth?

No. Traffic to and from managed databases does not count against your account's bandwidth transfer allowance, so sync frequency does not create a bandwidth charge.

Can I sync more than one billing provider into the same cluster?

Yes. Each provider writes to its own prefixed tables (stripe_, quickbooks_, xero_, paddle_), so they coexist in one database and can be joined together in a single query.

Is the 1 GiB entry tier enough?

For billing data alone, almost certainly. Storage is rarely the limit because billing tables are small. RAM is the thing to watch, and if the cluster is also serving application traffic, start one tier up at 2 GiB.

How is this different from syncing to AWS RDS?

Mainly cost predictability and setup effort. RDS needs VPC and security group configuration before anything external can connect; DigitalOcean needs the right port and an SSL parameter. RDS gives you a deeper ecosystem you probably do not need for a billing table.

Wrapping Up

DigitalOcean Managed PostgreSQL is a sensible home for billing data specifically because it is boring: a fixed price, a short list of tiers, and no bandwidth meter running in the background. Adding a usage-priced pipeline on top would reintroduce the unpredictability you picked it to avoid.

Get the connection string right, pick your provider, and the data lands as ordinary tables you can query with the tools you already use.

Try it at codelesssync.com

Related:

Xero API Integration Guide (2026): OAuth, Tenants, and Your First Query

ilshaad — Tue, 04 Aug 2026 09:41:44 +0000

Step-by-step Xero API integration: OAuth 2.0, tenant routing, paging, rate limits, the 2026 scope and pricing changes, plus a no-code path to PostgreSQL.

By Ilshaad Kheerdali · 4 August 2026

The Xero API is well documented and pleasant to work with once it clicks, but the first integration always takes longer than people expect. There is an extra discovery step that most accounting APIs don't have, tokens expire faster than you'd guess, and 2026 brought two changes that alter how you scope and budget an integration.

This guide walks the whole flow: creating an app, running OAuth 2.0, resolving which organisation you're actually talking to, making your first call, paging through results, staying inside the rate limits, and pulling incremental updates. At the end it covers what changed in 2026 and the shortcut if the plumbing isn't the part you want to own.

Everything below targets the Xero Accounting API over OAuth 2.0. Xero retired OAuth 1.0a some years ago, so any tutorial you find that mentions consumer keys and signed requests is out of date.

What the Xero API Is

The Xero Accounting API is a REST API that returns XML by default and JSON if you ask for it. You read and write accounting entities: Invoices, Contacts, Payments, BankTransactions, Accounts, CreditNotes, Items, PurchaseOrders, ManualJournals and a few dozen more, plus a set of report endpoints.

The thing that surprises most developers coming from Stripe or QuickBooks is the tenant model. A single Xero login can have access to many organisations: an accountant might be connected to two hundred client orgs. So authorisation and targeting are two separate concerns. Your token proves the user said yes, and a separate header tells Xero which organisation the call is for.

That means every integration has a step that a Stripe integration simply doesn't: after you get a token, you have to ask Xero which tenants that token can reach.

Step 1: Create a Xero App

Sign in at the Xero Developer portal and create an app.
Pick the grant type. Auth Code is what you want for a web server app that can keep a client secret safe. Native desktop and mobile apps use PKCE instead, and single page apps are not supported at all. Custom Connections are the machine-to-machine option for a single organisation, which suits internal tooling.
Set your redirect URI. It has to be an absolute HTTPS address and match exactly what you send during OAuth. http://localhost/ is allowed for local testing, but http://127.0.0.1 is not. You can register up to 50 per app.
Copy the Client ID and generate a Client Secret.

Xero gives you a Demo Company with realistic data, which is the sane place to develop. There is no separate sandbox host: you point at the same production API and authorise against the demo org.

Step 2: Authenticate with OAuth 2.0

Xero uses the standard authorization code flow. Send the user to Xero, they pick which organisation to connect, and you exchange the returned code for tokens.

// 1. Build the consent URL
const authUrl = new URL('https://login.xero.com/identity/connect/authorize');
authUrl.searchParams.set('response_type', 'code');
authUrl.searchParams.set('client_id', process.env.XERO_CLIENT_ID!);
authUrl.searchParams.set('redirect_uri', process.env.XERO_REDIRECT_URI!);
authUrl.searchParams.set(
  'scope',
  'openid profile email accounting.contacts.read accounting.invoices.read offline_access',
);
// CSRF guard. State only protects you if you store it and compare it on return.
const state = crypto.randomUUID();
await saveOAuthState(state);
authUrl.searchParams.set('state', state);

// 2. Exchange the code in your redirect handler
app.get('/callback', async (req, res) => {
  const expected = await takeOAuthState(); // read it once, then delete it
  if (!expected || req.query.state !== expected) {
    return res.status(400).send('Invalid state');
  }

  const basic = Buffer.from(
    `${process.env.XERO_CLIENT_ID}:${process.env.XERO_CLIENT_SECRET}`,
  ).toString('base64');

  const tokenRes = await fetch('https://identity.xero.com/connect/token', {
    method: 'POST',
    headers: {
      Authorization: `Basic ${basic}`,
      'Content-Type': 'application/x-www-form-urlencoded',
    },
    body: new URLSearchParams({
      grant_type: 'authorization_code',
      code: req.query.code as string,
      redirect_uri: process.env.XERO_REDIRECT_URI!,
    }),
  });

  const token = await tokenRes.json();
  // token.access_token  -> 30 minutes
  // token.refresh_token -> rotates on every use
});

Four details worth internalising before you build anything on top of this:

offline_access is not optional. Leave it out of your scope string and Xero won't issue a refresh token at all. You'll get thirty minutes of access and then a dead integration, which is a confusing thing to debug at 5pm.
The authorization code is single use and expires 5 minutes after issuance. If your callback handler is slow or you retry the exchange, you'll be looking at an invalid_grant error rather than an obvious timeout.
Access tokens last 30 minutes. Short, so refresh logic isn't something you can defer to "later". The id_token expires even faster, at 5 minutes.
Refresh tokens rotate. Every refresh returns a new refresh token and the old one stops working. Persist the new value in the same transaction you use it, or a crash mid-refresh will lock that connection out. Unused refresh tokens expire after 60 days. If a refresh call fails without a response, Xero lets you retry with the existing refresh token for a grace period of 30 minutes before you have to send the user back through consent.

async function refresh(storedRefreshToken: string) {
  const basic = Buffer.from(
    `${process.env.XERO_CLIENT_ID}:${process.env.XERO_CLIENT_SECRET}`,
  ).toString('base64');

  const res = await fetch('https://identity.xero.com/connect/token', {
    method: 'POST',
    headers: {
      Authorization: `Basic ${basic}`,
      'Content-Type': 'application/x-www-form-urlencoded',
    },
    body: new URLSearchParams({
      grant_type: 'refresh_token',
      refresh_token: storedRefreshToken,
    }),
  });

  const token = await res.json();
  await saveTokens(token); // token.refresh_token has changed. Save it.
  return token.access_token;
}

Step 3: Resolve the Tenant

This is the step people miss. Your access token does not identify an organisation, so before you can read anything you ask Xero what the token can reach:

const res = await fetch('https://api.xero.com/connections', {
  headers: {
    Authorization: `Bearer ${accessToken}`,
    'Content-Type': 'application/json',
  },
});

const connections = await res.json();
// [{
//   id: 'e1eede29-...',        // connection id, used to DELETE the connection
//   authEventId: 'd99ecdfe-...',
//   tenantId: '70784a63-...',  // this is what goes in the header
//   tenantType: 'ORGANISATION',
//   tenantName: 'Maple Florist',
//   createdDateUtc: '2019-07-09T23:40:30.1833130',
//   updatedDateUtc: '2020-05-15T01:35:13.8491980',
// }]
const tenantId = connections[0].tenantId;

Store tenantId next to the tokens. Every subsequent API call carries it in the Xero-tenant-id header. If it is missing, malformed, or not authorised for that token, Xero returns 403 Forbidden with "detail": "AuthenticationUnsuccessful", which is easy to misread as an expired token when the token is fine. The genuinely silent failure is the other one: a tenant the token is authorised for but that belongs to a different organisation returns 200 with that org's data, so a mixed-up tenant looks like missing records rather than an error.

Two things make this step subtler than it looks. First, the endpoint returns every tenant the user has ever connected, not just the ones authorised in this flow. If you want only the new ones, decode the authentication_event_id claim from the access token JWT and filter with ?authEventId=.... Second, tenantType is not always ORGANISATION: a user can connect a Practice Manager account too, and those entries come back with a null tenantName.

If your user connects several organisations, you'll need a way for them to pick. That is a genuine product decision, not just plumbing: agencies and bookkeepers routinely connect dozens of orgs, and as Step 6 shows, each one carries its own separate rate-limit budget.

Step 4: Make Your First API Call

The Accounting API lives under https://api.xero.com/api.xro/2.0/. Three headers on every request:

const BASE = 'https://api.xero.com/api.xro/2.0';

const res = await fetch(`${BASE}/Invoices`, {
  headers: {
    Authorization: `Bearer ${accessToken}`,
    'Xero-tenant-id': tenantId,
    Accept: 'application/json', // omit this and you get XML
  },
});

const { Invoices } = await res.json();
console.log(Invoices.length, Invoices[0]?.InvoiceNumber);

Two quirks to expect. Endpoints and response fields are PascalCase (Invoices, InvoiceNumber, AmountDue), which trips up anyone auto-mapping into snake_case Postgres columns. And dates come back in Microsoft's legacy JSON format, /Date(1712345678000+0000)/, so plan on parsing them rather than passing them straight into a timestamp column.

For filtering, Xero uses a where query parameter with its own expression syntax. It has to be percent encoded before you append it, and so does the space in an order clause:

const where = encodeURIComponent('Status=="AUTHORISED"&&Type=="ACCREC"');
const order = encodeURIComponent('Date DESC');
const url = `${BASE}/Invoices?where=${where}&order=${order}`;

Keep where clauses simple. Xero's own advice is to stick to == comparisons where you can, because long or complex expressions time out against larger organisations. The busiest endpoints also have dedicated parameters that are faster than a where: Invoices?Statuses=AUTHORISED, Invoices?ContactIDs=..., and IDs=... all take comma-separated lists. There's also summaryOnly=true on Invoices and Contacts, which strips the computation-heavy fields and is worth using when you're just building an index.

Step 5: Page Through Results

Xero pages with a simple page parameter, and pageSize controls how many records come back. The default is 100 and the maximum is 1,000, so always set it explicitly or you'll make ten times the calls you need to. Values outside the range are clamped rather than rejected, so pageSize=5000 quietly gives you 1,000.

Paging is available on Invoices, Contacts, CreditNotes, BankTransactions, ManualJournals, Payments, PurchaseOrders, Prepayments and Overpayments. It's worth using even when you don't need the volume: on several endpoints the unpaged response is a summarised version, so paged results come back with extra detail such as line items, and you avoid a follow-up request per record.

async function fetchAllInvoices(accessToken: string, tenantId: string) {
  const all = [];
  let page = 1;

  while (true) {
    const res = await fetch(
      `${BASE}/Invoices?page=${page}&pageSize=1000`,
      {
        headers: {
          Authorization: `Bearer ${accessToken}`,
          'Xero-tenant-id': tenantId,
          Accept: 'application/json',
        },
      },
    );

    const body = await res.json();
    all.push(...body.Invoices);

    // Paged responses carry a pagination object: page, pageSize, pageCount, itemCount
    if (page >= body.pagination.pageCount) break;
    page++;
  }

  return all;
}

The pagination object supersedes the older approach of fetching pages until one comes back short. If you're maintaining code that still does that, it works, but the object tells you itemCount and pageCount up front, which is what you want for progress reporting and for deciding whether a backfill will fit inside the daily call budget.

Step 6: Handle Rate Limits and Errors

Xero's limits are considerably tighter than most billing APIs, and they stack. As of 2026:

Limit	Value	Scope
Concurrent	5 calls in progress	Per organisation, per app
Per minute	60 calls	Per organisation, per app
Per day	1,000 calls on the Starter tier, 5,000 on Core and above	Per organisation, per app
App-wide	10,000 calls per minute	Across all your connections

The daily cap is the one that bites, and note that it is tiered, which is easy to miss because most write-ups quote a flat 5,000. On the free Starter tier you get 1,000 calls per day per organisation. A full backfill of a busy org, paged at 100 records because you forgot pageSize, can exhaust that before it finishes, and you are then locked out of that tenant until the window resets. The limits are per tenant rather than per app, so ten connected organisations means ten separate daily budgets.

You don't have to guess where you stand. Every response carries X-DayLimit-Remaining, X-MinLimit-Remaining and X-AppMinLimit-Remaining, so a scheduler can back off before it trips anything.

Exceeding a limit returns HTTP 429 with an X-Rate-Limit-Problem header naming which of the four you hit. For the minute and daily limits you also get a Retry-After header with the seconds to wait. The windows are fixed and reset at different times per tenant, so Retry-After is the only reliable signal:

if (res.status === 429) {
  const problem = res.headers.get('X-Rate-Limit-Problem'); // which limit tripped
  const retryAfter = res.headers.get('Retry-After');

  // Concurrent-limit 429s have no Retry-After. Back off briefly and retry.
  const waitSeconds = retryAfter ? Number(retryAfter) : 5;
  console.warn(`Hit ${problem} limit, waiting ${waitSeconds}s`);
  await new Promise((r) => setTimeout(r, waitSeconds * 1000));
}

Check Xero's current limits documentation before you size a backfill, since these numbers do get revised.

Step 7: Sync Incrementally with If-Modified-Since

Re-pulling everything on a schedule is exactly how you exhaust the daily cap. For updates, send the If-Modified-Since header with a UTC timestamp and Xero returns only records modified after it:

const res = await fetch(`${BASE}/Invoices?pageSize=1000`, {
  headers: {
    Authorization: `Bearer ${accessToken}`,
    'Xero-tenant-id': tenantId,
    Accept: 'application/json',
    'If-Modified-Since': '2026-07-01T00:00:00',
  },
});

Note the format: UTC, accurate to the second. The pattern is a full backfill once, then If-Modified-Since on a schedule with the watermark stored per tenant per endpoint. Xero explicitly recommends it for any endpoint with a large result set.

One caveat matters a lot if you're building a mirror of the data. The filter keys off UpdatedDateUTC, and Xero documents specific changes that don't bump that field: edits to partially paid transactions that don't generate a journal, such as DueDate or SentToContact, and Contact fields derived from elsewhere such as Balances, IsSupplier and IsCustomer. Records changed only in those ways will never appear in an incremental pull. If completeness matters, schedule a periodic full reconciliation pass rather than trusting the incremental stream indefinitely.

What Changed in 2026: Scopes and Pricing

Two changes landed in March 2026 that affect how you build and what it costs.

Granular scopes. Xero replaced three broad scopes with sixteen narrower ones. accounting.transactions splits into accounting.invoices, accounting.payments, accounting.banktransactions and accounting.manualjournals (plus the matching .read variants), and accounting.reports.read splits into eight report-specific scopes covering aged reports, balance sheet, bank summary, budget summary, executive summary, profit and loss, trial balance and tax reports. Scopes for settings, contacts, attachments and budgets were not affected.

Web and PKCE apps created from 2 March 2026 use granular scopes from the start, apps created before that date were assigned them by the end of April 2026, and custom connections followed on 29 April 2026. Broad scopes keep working until September 2027. The catch is that migration isn't a config change: because you're requesting a different permission set, every connected user has to consent again. Scopes are additive, so the usual approach is to update your authorisation link now, let re-authorisations and new organisations migrate people organically, then chase the remainder before the deadline.

Worth wiring up defensively: calling an endpoint whose granular scope you haven't requested returns a 401 with a WWW-Authenticate: insufficient_scope header, so catch that case specifically and prompt the user to update permissions rather than showing a generic auth error.

The API is no longer free. This is the bigger one, and it's easy to miss because most Xero tutorials predate it. Xero retired its revenue-share model on 2 March 2026 and replaced it with five tiers priced on two axes: how many organisations you're connected to, and how much data you pull.

Tier	Max connections	Monthly fee (AUD)	Included egress	Overage
Starter	5	Free	n/a	n/a
Core	50	$35	10 GB	$2.40/GB
Plus	1,000	$245	50 GB	$2.40/GB
Advanced	10,000	$1,445	250 GB	$2.40/GB
Enterprise	No limit	On application	On application	On application

Fees are tax exclusive, and allowances reset on the first of the calendar month (UTC). Billing is on data egress, so only data you download counts. Uploads into Xero are unlimited at every tier, and the Organisation endpoint is excluded from the calculation. Plus and above require app certification, and Advanced adds an annual security assessment, which also gates the premium endpoints: Journals, the Practice Manager API and bulk connections are Advanced-tier features.

Two things follow from this. First, an inefficient integration now has a line item. Paging at 100 instead of 1,000, re-pulling full history nightly, or syncing entities nobody queries used to be merely untidy, and now they show up on an invoice. Second, the free tier's 5-connection cap and 1,000 calls per day make it a testing tier rather than a production one, so budget for at least Core if you're shipping.

One more change landed alongside the pricing: the updated developer terms prohibit using data obtained from Xero's APIs to train, fine tune, adapt or enhance AI or ML models. If that was on your roadmap, read clause 7 of the developer platform terms and conditions before you build. Current tiers and allowances are on Xero's developer pricing page.

The Hard Parts

A first integration is very achievable. Keeping it healthy across many organisations is where the effort actually lands:

Token lifecycle at scale. Thirty-minute access tokens and rotating refresh tokens, per tenant, with safe persistence and a recovery path when a refresh fails.
Per-tenant rate budgets. Limits are per organisation, so a hundred connected orgs means a hundred separate budgets to schedule against without tripping the app-wide ceiling.
Schema mapping. PascalCase fields, /Date(...)/ timestamps, nested LineItems, and per-endpoint quirks all need flattening before the data is queryable.
Scope migration. If your app predates March 2026, the September 2027 deadline is a re-authorisation campaign across your entire user base.
Egress awareness. Sync design is now a cost decision, not just an engineering one.

If you're still weighing whether to build this at all, Xero API vs Database Sync works through the build-versus-buy maths in detail.

A Simpler Path: Sync Xero to PostgreSQL with No Code

If the goal is simply having Xero data in your own database to query and report on, none of the above is differentiating work. Codeless Sync connects Xero to your PostgreSQL database (Supabase, Neon, Railway, AWS RDS, or any Postgres host) in about five minutes. You authorise Xero once, pick your organisation, and CLS handles token refresh, tenant routing, paging, rate-limit backoff, incremental pulls and table creation. Data lands as clean relational tables:

-- Outstanding receivables by contact, oldest first
SELECT c.name,
       SUM(i.amount_due) AS outstanding,
       MIN(i.due_date)   AS oldest_due
FROM xero_invoices i
JOIN xero_contacts c ON c.id = i.contact_id
                    AND c.tenant_id = i.tenant_id
WHERE i.status = 'AUTHORISED'
  AND i.type = 'ACCREC'
  AND i.amount_due > 0
GROUP BY c.name
ORDER BY oldest_due ASC;

CLS also offers incremental pulls (last day, last 7 days, last 30 days) alongside a full sync, so once the backfill is done a scheduled run fetches only what changed rather than spending your daily call budget and egress allowance on history you already have. Pricing is a flat monthly fee rather than usage-metered, so your bill doesn't move when your invoice volume does. There's a free tier and no credit card required.

For the step-by-step version, see How to Sync Xero to PostgreSQL Automatically in 5 Minutes, or the Xero to PostgreSQL overview.

Frequently Asked Questions

Is the Xero API free to use?

Not really, since March 2026. Xero replaced its revenue-share model with five tiers priced on connection count and data egress, effective 2 March 2026. There is a free Starter tier, but it caps you at 5 connections and 1,000 API calls per day per organisation, which suits testing rather than production. The next step up is Core at $35 AUD per month for 50 connections and 10 GB of monthly egress. Only data you download counts toward the allowance; writing data into Xero is unlimited at every tier.

How long do Xero access tokens last?

Access tokens expire after 30 minutes. Refresh tokens rotate on every use and expire after 60 days if unused, so you must persist the new refresh token each time you refresh or you'll lose the connection.

What is the Xero-tenant-id header and why do I need it?

A Xero access token can have access to multiple organisations, so the token alone doesn't say which one you mean. You call GET https://api.xero.com/connections to list the tenants the token can reach, then pass the chosen tenantId in the Xero-tenant-id header on every Accounting API request.

What are the Xero API rate limits?

As of 2026: 5 concurrent calls, 60 calls per minute, and a daily cap that depends on your tier (1,000 calls per day on Starter, 5,000 on Core and above). Those are measured per organisation per app, so each connected tenant has its own budget. There is also an app-wide ceiling of 10,000 calls per minute across all connections. Exceeding any of them returns HTTP 429 with an X-Rate-Limit-Problem header naming the limit, plus a Retry-After header for the minute and daily limits.

Can I sync Xero data to PostgreSQL without writing code?

Yes. Codeless Sync handles the OAuth flow, tenant selection, token refresh, paging and schema mapping, writing Xero data straight into PostgreSQL tables. You authorise once and it stays in sync on a schedule.

Related:

How to Export Paddle Data to a Database

ilshaad — Mon, 27 Jul 2026 14:12:24 +0000

How to export Paddle data to a database: dashboard CSV reports, the Reports API, the Paddle API, Zapier, and no-code sync. Pros, cons, and real costs.

By Ilshaad Kheerdali · 27 July 2026

Paddle reports build asynchronously, carry up to 24 hours of lag, and delete themselves after 14 days. The API is fresher, but it hands you transactions 30 at a time behind a cursor. Neither one is an export, and if you run your billing on Paddle you have probably already hit that wall.

The awkward part is that "export Paddle data to a database" sounds like it should be a single button. It isn't. Five different methods exist, each solving a different slice of the problem, and most of them either go stale before you download them, expire before you use them, or leave you maintaining a pipeline that quietly breaks at 3am.

This guide walks through all five practical ways to get Paddle Billing data into a real, queryable database: dashboard CSV reports, the Reports API, the Paddle API directly, Zapier-style automation, and no-code sync. What each one costs, and where each one breaks.

Why Exporting Paddle Data Is Harder Than It Should Be

As a merchant of record, Paddle is the system of record for your revenue, not just another payment processor. It holds your customers, subscriptions, transactions, and adjustments, and it handles the sales tax filing on top. That makes a queryable local copy more valuable than it would be elsewhere, and it also makes the data harder to get at than most teams expect.

Built-in reports are asynchronous snapshots. Paddle Billing generates CSV reports for transactions, transaction line items, adjustments, adjustment line items, products and prices, discounts, checkouts, and payout reconciliation, but each report has to be built, then downloaded before it expires (files are kept for 14 days). And the data inside a report can be delayed by up to 24 hours, so even a fresh export isn't fully current.

There's no bulk "export everything" endpoint. Paddle's API is designed to run a billing system, so every entity (customers, subscriptions, transactions, products, prices) is its own set of cursor-paginated list calls. Page sizes vary by endpoint, and transactions cap at 30 records per page. A busy account means hundreds of sequential requests per entity, stitched back together in order.

Webhooks notify about new events only. Paddle notifications are push-based and start capturing from the moment you create the destination. Your historical transactions and existing subscribers never flow through them, so webhooks can't backfill a database. (For the full webhook trade-off, see Paddle Webhooks vs Database Sync.)

You configure everything twice. Sandbox and production are isolated Paddle environments with their own API keys, so a report you build or a pipeline you script against sandbox has to be recreated, and re-verified, against live data before you trust the numbers.

So the job falls to one of five approaches. Here is how each one holds up.

5 Ways to Export Paddle Data to a Database

Method 1: Manual Paddle CSV Export from the Dashboard

The simplest option. In the Paddle dashboard, go to Reports, find the report type you need under the Build reports tab (transactions, adjustments, transaction line items, products and prices, or discounts), click Build report, filter the date range, then click Generate report. Paddle emails you once the file is ready. The output is a UTF-8, comma-delimited CSV.

Once you have the file, you import it from your own machine with psql's \copy command (the server-side COPY FROM variant needs filesystem access on the database server, which managed hosts like Supabase, Neon, and RDS don't give you):

\copy paddle_transactions_export (transaction_id, customer_id, status, currency, total, billed_at) FROM 'paddle-transactions.csv' CSV HEADER

Create the destination table before you run that, and check the column list against the file: CSV HEADER skips the header row, it does not match columns by name, so the order has to line up. Paddle's transaction report ships a lot more columns than the six above, so trim the file or list every column.

Pros:

Free and built into Paddle
No code, no API setup, no developer required
Useful for one-off analysis or a finance handoff

Cons:

Report data can lag up to 24 hours, so the export is stale before you even download it
Asynchronous: you request the report, wait for it to build, then download
Files expire 14 days after creation; miss the window and you rebuild the report
Manual every time. If you need fresh data weekly, you're clicking through this every week
Each report type is separate, so a full dataset means several builds and several imports
No automation, no incremental updates, no joins with your application data

Dashboard reports are fine when someone in finance needs a spreadsheet once a quarter. As a way to keep a database current, they fall over immediately.

Method 2: Automate the Reports API

Paddle exposes the same reporting engine over the API: POST /reports creates a report, you poll until its status is ready (or listen for the report.updated notification), then call the download-url endpoint to get a link to the CSV. That link expires after 72 hours, and the report itself stays available for 14 days, so you can request a fresh link at any point inside that window.

Pros:

Scriptable version of Method 1; can run on a schedule
Same broad report types as the dashboard
Good fit if you already have a data pipeline that ingests CSV files

Cons:

You're building a pipeline anyway: create, poll, download via an expiring link, parse CSV, load, dedupe
Inherits Method 1's data lag, so your database is always up to a day behind
CSV column layouts follow the report, so you still design the table schema and upserts yourself
Sandbox/live duplication, credential storage, and failure alerting are all on you

This is a legitimate middle path for data teams, but by the time it runs reliably on a schedule, you've built and now own a small ETL system.

Method 3: Direct Paddle API Integration

If you need current data and you're comfortable writing code, you can pull directly from the Paddle API's list endpoints and write the results into PostgreSQL yourself.

A minimal version looks like this:

import { Pool } from 'pg';

const pool = new Pool({ connectionString: process.env.DATABASE_URL });

async function exportTransactions() {
  let url: string | null = 'https://api.paddle.com/transactions?per_page=30';

  while (url) {
    const response = await fetch(url, {
      headers: { Authorization: `Bearer ${process.env.PADDLE_API_KEY}` },
    });
    const json = await response.json();

    for (const tx of json.data ?? []) {
      await pool.query(
        `INSERT INTO paddle_transactions_raw (id, customer_id, status, currency_code, grand_total, billed_at, updated_at)
         VALUES ($1, $2, $3, $4, $5, $6, $7)
         ON CONFLICT (id) DO UPDATE
         SET status = $3, grand_total = $5, updated_at = $7`,
        [
          tx.id,
          tx.customer_id,
          tx.status,
          tx.currency_code,
          tx.details?.totals?.grand_total ?? 0,
          tx.billed_at,
          tx.updated_at,
        ],
      );
    }

    url = json.meta?.pagination?.has_more ? json.meta.pagination.next : null;
  }
}

That hand-rolled schema is not the same as the table Codeless Sync creates, which stores details.totals.total in a column called total. Keep the two apart, or the SQL further down this page won't run against your table.

Pros:

Real, current data on demand, no report lag
Full control over which entities you export and how they map to your schema
Simple Bearer-key auth for your own account, so there are no OAuth tokens to refresh the way QuickBooks and Xero require

Cons:

Cursor pagination with small pages: transactions cap at 30 records per page, so large accounts mean many requests per run
Rate limiting, retries on 429s, and error recovery are all on you
Amounts arrive as strings of integer minor units inside nested objects (details.totals.grand_total), so schema mapping and type conversion are manual work
Each new entity (customers, subscriptions, products, prices, adjustments, discounts) is another loop, another schema, another set of edge cases
Sandbox and live need separate configuration and testing
Maintenance is forever. The build is the easy part

For most teams the arithmetic is simple: a weekend to build it, then an open-ended commitment to keep it alive as Paddle's API and your own schema both move.

Method 4: Zapier, Make, or Generic Automation Platforms

If you want fresh data without writing code, automation platforms can catch Paddle webhooks. Neither Zapier nor Make has a native Paddle trigger (Make's Paddle app is actions-only, and Zapier has no Paddle app at all), but both have generic webhook modules. You point Paddle's transaction.completed webhook at a catch-hook URL, then map the payload fields to a PostgreSQL insert action.

Pros:

No code required, though you do set up a webhook destination and map fields by hand
Both platforms have solid PostgreSQL insert actions
Reasonable for low-volume, single-trigger use cases

Cons:

No historical backfill; only future events trigger the automation. Your existing customers, subscriptions, and transaction history stay outside the database unless you export them separately
Per-task pricing scales with your sales volume; a growing subscription business generates a lot of events
Limited transformation logic; anything beyond direct field mapping needs custom code steps, which take you back toward Method 3
Failures retry, but silently; debugging a stuck automation is painful
Your "export pipeline" lives inside a third-party automation account, not your codebase

Automation platforms earn their place on single-trigger flows. Asking one to hold a complete, current copy of your Paddle data is asking it to act as a replication tool, which it was never built to be.

Method 5: A Purpose-Built No-Code Sync (Codeless Sync)

Codeless Sync was built for exactly this problem: getting API data into a PostgreSQL database without writing code and without a report-lag delay, then keeping it there without a pipeline to maintain.

How it works:

Connect your PostgreSQL database via connection string (Supabase, Neon, AWS RDS, Railway, Heroku, or self-hosted)
Add your Paddle API key (read access is enough)
Pick which data to export (customers, subscriptions, transactions, products, prices, adjustments, or discounts)
The destination table is auto-created with the right schema and indexes
Run the first export: a full sync pulls your complete history. Schedule recurring syncs, or trigger them manually

Pros:

No code to write, and no report polling or pagination loops left running
Historical backfill plus ongoing incremental updates in one workflow (no 24-hour report lag)
Works with any PostgreSQL host
Free tier for small projects, flat predictable pricing as you scale
Setup takes about 5 minutes

Cons:

Runs in batches on a schedule (webhooks remain the right tool for instant reactions like access provisioning)
Currently focused on Stripe, QuickBooks, Xero, and Paddle; not a general-purpose ETL tool

If what you want is a current, queryable copy of your Paddle data sitting in your own database, this is the shortest route to it.

Comparison: Which Paddle Export Method Fits Your Use Case?

Method	Setup time	Keeps data current?	Best for	Cost
Dashboard CSV report	Minutes	No; async snapshot, up to 24h data lag	A finance handoff you do once a quarter	Free
Reports API pipeline	Days	Partial; scheduled but inherits report lag	Teams already loading CSV feeds on a schedule	Server time plus the build
Direct Paddle API	Days to weeks	Yes, if you maintain the polling	A custom entity mix worth the engineering	Server time plus ongoing upkeep
Zapier / Make	Hours	Partial; future events only, no backfill	Reacting to one Paddle event at low volume	Per-task, rises with sales volume
Codeless Sync	~5 minutes	Yes; backfill plus scheduled incremental	Anyone who wants the data there and current	Free tier, then flat plans

Read down the table and the trade is clear enough. The free routes hand you a snapshot that is already stale and will delete itself. The API hands you freshness in exchange for permanent upkeep. The automation platforms only ever see what happens next. A purpose-built sync is the one option that gives you history and freshness without putting a pipeline in your name.

What You Can Do Once Paddle Data Is in PostgreSQL

Paddle's own reporting can tell you what happened inside Paddle. Once the same data is in Postgres, you can ask questions Paddle has no way to answer, because you can join your billing records against your application's tables and against each other.

The queries below run against the tables Codeless Sync creates. Paddle returns amounts as strings in the lowest denomination for the currency (cents for USD, pence for GBP), so totals are cast to numeric and divided by 100. Most currencies use two decimal places, but a few (JPY, for example) use none, so adjust the divisor if you sell in those. If you sell in more than one currency, add AND currency_code = 'USD' or group by currency_code, since every row is stored in its original currency. Add AND livemode = true to keep sandbox rows out of the numbers.

Monthly revenue with month-over-month growth:

WITH monthly_revenue AS (
  SELECT
    DATE_TRUNC('month', billed_at) AS month,
    SUM(total::NUMERIC) / 100.0 AS revenue,
    COUNT(*) AS transaction_count
  FROM paddle_transactions
  WHERE status = 'completed'
  GROUP BY 1
)
SELECT
  month,
  revenue,
  transaction_count,
  ROUND(
    100.0 * (revenue - LAG(revenue) OVER (ORDER BY month))
    / NULLIF(LAG(revenue) OVER (ORDER BY month), 0),
    1
  ) AS mom_growth_pct
FROM monthly_revenue
ORDER BY month DESC
LIMIT 12;

Refund and chargeback rate from adjustments:

WITH adj AS (
  SELECT
    DATE_TRUNC('month', created_at) AS month,
    COUNT(*) FILTER (WHERE action = 'refund' AND status = 'approved') AS refunds,
    COUNT(*) FILTER (WHERE action = 'chargeback' AND status = 'approved') AS chargebacks
  FROM paddle_adjustments
  GROUP BY 1
),
tx AS (
  SELECT
    DATE_TRUNC('month', billed_at) AS month,
    COUNT(*) AS completed_transactions
  FROM paddle_transactions
  WHERE status = 'completed'
  GROUP BY 1
)
SELECT
  a.month,
  a.refunds,
  a.chargebacks,
  ROUND(
    100.0 * (a.refunds + a.chargebacks) / NULLIF(t.completed_transactions, 0),
    2
  ) AS refund_chargeback_rate_pct
FROM adj a
LEFT JOIN tx t ON t.month = a.month
ORDER BY a.month DESC;

Trial-to-paid conversion by cohort (only possible with full history):

SELECT
  DATE_TRUNC('month', started_at) AS cohort_month,
  COUNT(*) AS subscriptions_started,
  COUNT(*) FILTER (WHERE first_billed_at IS NOT NULL) AS converted_to_paid,
  ROUND(
    100.0 * COUNT(*) FILTER (WHERE first_billed_at IS NOT NULL)
    / NULLIF(COUNT(*), 0),
    1
  ) AS conversion_pct
FROM paddle_subscriptions
WHERE started_at IS NOT NULL
  AND livemode = true
GROUP BY 1
ORDER BY cohort_month DESC
LIMIT 12;

That last one is the query a webhook-fed table can never answer, because the cohorts you most want to measure started before you set the webhook up. That is what a real export gets you: a queryable dataset sitting next to your application data, ready for dashboards or alerts, instead of a CSV that deletes itself in 14 days. For ready-made metric queries, see How to Calculate MRR, Churn, and LTV in PostgreSQL.

Step-by-Step: Set Up an Automated Paddle Export in 5 Minutes

If Method 5 looks like the right fit, the whole setup is four things: paste your PostgreSQL connection string, add a Paddle API key with Permissions set to Read for All (it's encrypted at rest), let the wizard auto-create the destination table, then run the first export. Transactions is the data type to start with, since it's your revenue record, and the Paddle transactions SQL template shows the exact schema you'll get.

That first run is a full backfill, so your complete history lands in the table rather than only what happens from now on. After that you either trigger exports manually or put them on a schedule (every 12 hours, daily, weekly, or monthly, depending on your plan). Repeat the wizard for customers, subscriptions, or any other data type, and each one becomes its own table on the same cadence.

The free tier covers small projects without a credit card, and the full walkthrough, including which PostgreSQL hosts are supported, lives on the Paddle to PostgreSQL page.

Frequently Asked Questions

Can I export Paddle data without using the API?

Yes, via a Paddle CSV export from the dashboard: go to Reports, build the report type you need (transactions, adjustments, line items, products and prices, or discounts), and download the CSV once Paddle emails you that it's generated. This works for one-off analysis, but reports build asynchronously, the data inside can lag up to 24 hours, and files expire after 14 days. For an ongoing, current copy of your data, you'll want one of the automated methods, either built on the API yourself or handled by a sync tool like Codeless Sync.

Does Paddle have a full data export or backup option?

Not as a single button. Exports are per report type in the dashboard, or per entity through the API's paginated list endpoints. A complete picture of your billing data means several separate exports, repeated whenever you need fresh data. This is the main reason teams reach for a sync tool: a complete, continuously updated copy in one database is exactly what those tools produce.

What's the best way to export Paddle data to PostgreSQL?

It depends on freshness needs and engineering time. For a one-time snapshot, a dashboard report plus a psql \copy import is fastest. For a current, queryable copy with minimal maintenance, a no-code sync is the lowest-effort path and avoids the report lag entirely. Building directly against the Paddle API gives the most control, but you own cursor pagination (transactions cap at 30 records per page), rate-limit handling, and schema mapping forever.

How long are Paddle report exports available?

Generated report files are available to download for 14 days after creation, and each download URL the API returns expires after 72 hours, so you can request a fresh link at any point inside that 14-day window. Reports are best treated as one-off snapshots rather than an archive. If you need a permanent, queryable history, load the data into your own database, then the retention question disappears.

How fresh will my exported Paddle data be?

That depends entirely on the method. A dashboard report or a Reports API pull can be up to 24 hours behind before you even download it, because Paddle builds those asynchronously. Anything that reads the API directly, including a sync tool, is current as of the moment the run starts. So if the number you are looking at needs to match what Paddle's dashboard says right now, rule out the report-based methods. For monthly finance reviews a daily run is plenty; for internal dashboards and MRR tracking, twice a day keeps the numbers feeling live. Codeless Sync runs manual syncs on the free tier, and paid tiers add scheduled runs from every 12 hours down to monthly, depending on plan.

Need a current, queryable copy of your Paddle data without babysitting reports or pagination loops? Codeless Sync has a free tier, no credit card required. For the webhook side of the story, see Paddle Webhooks vs Database Sync.

Related:

How to Export Xero Data to a Database

ilshaad — Mon, 20 Jul 2026 11:19:58 +0000

Compare 5 ways to export Xero data to a database: CSV report exports, the Xero API, Zapier, ETL platforms, and no-code sync. Honest pros, cons, and costs.

By Ilshaad Kheerdali · 20 July 2026

If you run your accounting on Xero, you've probably hit a wall trying to get the data out. There is no one-click "export everything" button. Contacts export from one screen, invoices from another, reports from a third, and every file is a static snapshot that's stale the moment you download it. The API works, but only after you register an app, wire up OAuth 2.0, and babysit tokens forever.

The frustrating part is that "export Xero data to a database" sounds like it should be simple. It isn't. Different methods exist for different needs, and most of them either go stale immediately, cost more than they should, or leave you maintaining a pipeline that quietly breaks at 3am.

This guide walks through the five practical ways to export Xero data into a real, queryable database: CSV exports, the Xero API directly, Zapier-style automation, enterprise ETL platforms, and no-code sync. Honest pros, honest cons, and what each one actually costs to run.

Why Exporting Xero Data Is Harder Than It Should Be

Xero holds the data you care about: contacts, invoices, payments, bank transactions, the whole accounting picture. But getting it out in a form you can actually use takes more work than most teams expect.

Built-in exports are per-screen snapshots. Xero lets you export contacts, invoices, and bills as CSV files, and reports as Excel, PDF, or Google Sheets, but each data type exports separately from its own screen. A complete picture of your accounts means running several exports, and every one is frozen in time the second you download it.

There's no bulk "export everything" endpoint. The Xero API is built for transactional access, not data extraction. Invoices page through 100 records at a time (up to 1,000 with the pageSize parameter), contacts are a separate set of calls, payments another. For a complete dataset you're making dozens of calls and stitching the responses together.

List calls hide the detail you actually need. Ask the API for a list of invoices and it returns trimmed summaries with no line items, to keep responses fast. Getting the full records means fetching them individually or paging with larger page sizes, so a single "get my invoices" is rarely one call.

Webhooks notify but don't deliver data. Xero webhooks only fire for four things (contacts, invoices, credit notes, and App Store subscriptions), and the payload carries just a reference to the record, not the record itself. You still call the API to fetch what changed, which means you're maintaining the polling layer regardless.

OAuth 2.0 is non-negotiable. Every Xero integration needs a registered app, a consent flow, and token management. Access tokens last 30 minutes, and the refresh token is single-use with a rolling 60-day life: every refresh returns a new refresh token and invalidates the old one. Store the wrong one and your export job silently stops working. (For the full breakdown of the integration burden, see Xero API vs Database Sync.)

The result is that "export Xero data to a database" gets solved one of five ways. Here they are.

5 Ways to Export Xero Data to a Database

Method 1: Manual CSV / Excel Exports from Xero

The simplest option. From inside Xero, export each data type from its own screen: Contacts → Export for your customer and supplier list, Business → Invoices → Export for invoices and bills, and the Reports section for the General Ledger, Trial Balance, and other reports (which export to Excel, PDF, or Google Sheets; notably, Xero's newer reports don't offer CSV).

Once you have a file, you import it into your database with a COPY statement or a one-off script:

COPY xero_invoices_export (invoice_number, contact_name, invoice_date, total, amount_due)
FROM '/path/to/xero-invoices.csv'
DELIMITER ','
CSV HEADER;

Pros:

Free and built into Xero
No code, no API setup, no developer required
Useful for one-off analysis or sending to an accountant

Cons:

Stale the moment you click export; the file represents a single point in time
Manual every time. If you need fresh data weekly, you're running this every week
Each data type exports separately, so a full dataset means many separate exports from different screens
Column layouts differ between screens and reports, so your import scripts need per-file handling
No automation, no incremental updates, no joins with your application data

CSV exports are fine for a quarterly accountant handoff. They are not a database export strategy.

Method 2: Direct Xero API Integration

If you need fresh data and you're comfortable writing code, you can pull directly from the Xero Accounting API and write the results into PostgreSQL yourself.

Here's a stripped-down example in TypeScript:

import { Pool } from 'pg';

const pool = new Pool({ connectionString: process.env.DATABASE_URL });

async function exportInvoices(accessToken: string, tenantId: string) {
  let page = 1;

  while (true) {
    const response = await fetch(
      `https://api.xero.com/api.xro/2.0/Invoices?page=${page}&pageSize=1000`,
      {
        headers: {
          Authorization: `Bearer ${accessToken}`,
          'Xero-tenant-id': tenantId,
          Accept: 'application/json',
        },
      },
    );

    const json = await response.json();
    const invoices = json.Invoices ?? [];

    for (const inv of invoices) {
      await pool.query(
        `INSERT INTO xero_invoices (xero_id, invoice_number, contact_name, type, status, total, amount_due, updated_at)
         VALUES ($1, $2, $3, $4, $5, $6, $7, $8)
         ON CONFLICT (xero_id) DO UPDATE
         SET status = $5, total = $6, amount_due = $7, updated_at = $8`,
        [
          inv.InvoiceID,
          inv.InvoiceNumber,
          inv.Contact?.Name ?? null,
          inv.Type,
          inv.Status,
          inv.Total ?? 0,
          inv.AmountDue ?? 0,
          inv.UpdatedDateUTC,
        ],
      );
    }

    if (invoices.length < 1000) break;
    page += 1;
  }
}

Pros:

Real, current data on demand
Full control over which data types you export and how they map to your schema
Free in tooling cost; you only pay for the infrastructure that runs it

Cons:

OAuth 2.0 setup: app registration, consent flow, redirect URI handling, and token storage
Access tokens expire every 30 minutes, and the single-use refresh token must be re-persisted on every refresh
One Xero login can cover several organisations, so you also enumerate tenants and send the right Xero-tenant-id header on every call
Rate limiting is on you: 60 calls per minute per organisation, 5 concurrent requests, plus a daily cap
Incremental sync via If-Modified-Since has blind spots (some changes never bump UpdatedDateUTC), so you still need periodic full reconciliation
Each new data type (contacts, payments, bank transactions, credit notes) is another query, another schema, another set of edge cases
Maintenance is forever. The build is the easy part

This is the right path if your needs are unusual or you have engineering time to spare. For most teams, the upkeep cost outweighs the benefit.

Method 3: Zapier, Make, or Generic Automation Platforms

If you want fresh data without writing code, automation platforms like Zapier and Make have pre-built Xero triggers. You can wire up "when an invoice is created in Xero, insert a row into Postgres" and it just works.

Pros:

No code required
Decent library of triggers: new invoice, new contact, new payment, and so on
Quick to set up for simple flows

Cons:

Per-task pricing scales fast. A growing business with thousands of monthly invoices can hit the higher tiers within a couple of months
No historical backfill; only future events trigger zaps. Your existing contacts and invoices stay outside the database unless you export them separately
Limited transformation logic. Anything more complex than a direct field mapping needs custom code steps, which take you back toward the territory of Method 2
Failures retry, but silently; debugging a stuck zap is painful
Vendor lock-in. Your "data export pipeline" lives inside a Zapier account, not in your codebase

Zapier-style platforms work for single-trigger flows. They're a poor fit for "I want a complete, current copy of my Xero data in Postgres."

Method 4: Enterprise ETL Platforms (Fivetran, Airbyte)

General-purpose ETL platforms have Xero connectors and will land your data in a warehouse or database on a schedule, alongside hundreds of other sources.

Pros:

Mature scheduling, monitoring, and retry infrastructure
Handles many sources beyond accounting, useful if you're already consolidating a large data stack
Managed OAuth and rate-limit handling

Cons:

Usage-based pricing (Fivetran bills by monthly active rows) is hard to predict and usually overkill for one accounting sync
Self-hosting Airbyte trades the subscription for your own infrastructure and upgrade maintenance
Built for data teams feeding warehouses, so setup assumes more data-engineering context than most small teams have
A heavyweight platform for what is, for most readers, a single-source job

If you already run a Fivetran or Airbyte stack, adding Xero to it is reasonable. Adopting one just to export your accounting data is like buying a truck to deliver one parcel.

Method 5: A Purpose-Built No-Code Sync (Codeless Sync)

Codeless Sync was built for exactly this problem: getting API data into a PostgreSQL database without code, without ETL infrastructure, and without per-row pricing.

How it works:

Connect your PostgreSQL database via connection string (Supabase, Neon, AWS RDS, Railway, Heroku, or self-hosted)
Authorize Xero with one click; the OAuth consent, token storage, and refresh are handled for you
Pick which data to export (contacts, invoices, payments, accounts, bank transactions, credit notes, items, purchase orders, journals, or organisation details)
The destination table is auto-created with the right schema and indexes
The first export runs immediately. Schedule recurring syncs, or trigger them manually

Pros:

No code, no OAuth plumbing, no token refresh maintenance
Historical backfill plus ongoing incremental updates in one workflow
Works with any PostgreSQL host
Free tier for small projects, flat predictable pricing as you scale
Setup takes about 5 minutes

Cons:

Batch-based, not real-time (though incremental syncs run as often as every minute on paid plans)
Currently focused on Stripe, QuickBooks, Xero, and Paddle; not a general-purpose ETL tool

This is the recommended path if your goal is a current, queryable copy of your Xero data in your own database, with the lowest possible maintenance burden.

Comparison: Which Export Method Fits Your Use Case?

Method	Setup time	Keeps data current?	Best for	Cost
CSV / Excel exports	Minutes	No; single snapshot per screen	One-off accountant handoffs	Free
Direct Xero API	Days to weeks	Yes, if you maintain the polling	Bespoke integrations with engineering capacity	Infrastructure only, plus dev time
Zapier / Make	Hours	Partial; future events only, no backfill	Single-trigger flows for small volumes	Tiered, scales with task volume
Fivetran / Airbyte	Hours to days	Yes; scheduled connector runs	Data teams already running a multi-source stack	Usage-priced or self-hosted infra
Codeless Sync	~5 minutes	Yes; backfill plus scheduled incremental	Developers and small teams who want it to just work	Free tier, then flat plans

The split is roughly: free options give you stale per-screen files, the API gives you fresh data at the cost of forever-maintenance, automation platforms work until your volume grows, enterprise ETL works if you already own the stack, and a purpose-built sync sits in the middle: fresh data, low maintenance, predictable cost.

What You Can Do Once Xero Data Is in PostgreSQL

The whole point of exporting Xero data into a database is what becomes possible afterwards. With the data in Postgres, you have full SQL access to everything, and you can join it with your application's own tables.

Monthly sales revenue with month-over-month growth:

WITH monthly_revenue AS (
  SELECT
    DATE_TRUNC('month', invoice_date) AS month,
    SUM(total) AS revenue,
    COUNT(*) AS invoice_count
  FROM xero_invoices
  WHERE type = 'ACCREC'          -- sales invoices, not supplier bills
    AND status = 'PAID'
  GROUP BY 1
)
SELECT
  month,
  revenue,
  invoice_count,
  ROUND(
    100.0 * (revenue - LAG(revenue) OVER (ORDER BY month))
    / NULLIF(LAG(revenue) OVER (ORDER BY month), 0),
    1
  ) AS mom_growth_pct
FROM monthly_revenue
ORDER BY month DESC
LIMIT 12;

Outstanding receivables by contact:

SELECT
  contact_name,
  SUM(amount_due) AS outstanding_balance,
  COUNT(*) AS unpaid_invoices,
  MIN(due_date) AS oldest_due_date
FROM xero_invoices
WHERE type = 'ACCREC'
  AND amount_due > 0
  AND status IN ('AUTHORISED', 'SUBMITTED')
GROUP BY contact_name
ORDER BY outstanding_balance DESC;

Net position: what you're owed vs what you owe:

SELECT
  type,                                     -- ACCREC = sales invoices, ACCPAY = bills
  COUNT(*) FILTER (WHERE amount_due > 0) AS open_invoices,
  SUM(amount_due) AS outstanding
FROM xero_invoices
WHERE status IN ('AUTHORISED', 'SUBMITTED')
GROUP BY type;

This is what a real export gets you. Not a folder of per-screen CSV files, but a queryable dataset that lives next to your application data, ready for dashboards, alerts, or any analysis you want to run.

Step-by-Step: Export Xero to Postgres with Codeless Sync

If Method 5 looks like the right fit, the setup itself takes about five minutes:

Create a Codeless Sync account. The free tier covers small projects without a credit card.
Add your PostgreSQL database. Paste your connection string. Codeless Sync tests the connection before saving.
Open the configuration wizard and choose Xero as the source. Pick the data type you want first; contacts is a good starting point because it's easy to verify.
Click Connect to Xero and authorize through Xero's standard consent screen, then pick which organisation to sync. The OAuth flow, token storage, and refresh loop are handled automatically.
Auto-create the destination table. Codeless Sync builds the schema for you, with the right column types and indexes. If you'd rather review the SQL first, copy the template and run it manually.
Run the first export. The full backfill pulls every matching record. For most organisations this takes seconds to a couple of minutes.
Schedule recurring exports (every minute, hourly, or daily depending on your plan), or trigger them manually from the dashboard.

When the run finishes, your Xero data is in your Postgres database. Repeat the wizard for invoices, payments, or any other data type you need. Each one becomes its own table, each one stays current.

For a deeper walkthrough including the full Xero setup flow, see the step-by-step Xero-to-PostgreSQL sync guide.

Frequently Asked Questions

Can I export Xero data without using the API?

Yes. The no-API option is to export each data type from its own screen inside Xero (contacts, invoices, bills) or export reports as Excel, PDF, or Google Sheets. This works for one-off analysis but produces static files that are stale the moment they're downloaded, and a complete dataset means several separate exports. For ongoing access, every other method eventually involves the Xero API in some form; the question is whether you build that integration yourself or use a tool that handles it for you. A no-code sync like Codeless Sync uses the API behind the scenes so you don't have to.

Does Xero have a full backup or bulk export option?

Not in the way developers usually mean it. There's no single button or API endpoint that returns all of your data at once. Xero's own guidance is to export each data type separately: contacts from the Contacts screen, invoices and bills from the Business menu, and the General Ledger and other reports from the Reports section. This is the main reason most teams reach for a sync tool; a complete, current copy of your data in one place is exactly what those tools do.

What's the best way to export Xero data to PostgreSQL?

It depends on how often the data needs to refresh and how much engineering time you can spare. For a one-time export, per-screen CSV files plus a COPY statement is fastest. For a current, queryable copy of your Xero data with minimal maintenance, a no-code sync tool is the lowest-effort path. Building directly against the Xero API gives you the most control but the highest ongoing maintenance cost: 30-minute access tokens, single-use refresh tokens, tenant routing, and rate limits are all yours to manage.

How often should I export Xero data?

It depends on what you're using the data for. For monthly accounting reviews, daily syncs are plenty. For internal dashboards or cash-flow monitoring, hourly updates feel close to live. For event-driven workflows (like flagging overdue invoices to your ops team), you'll want incremental syncs running at least every 5-15 minutes. Codeless Sync supports schedules from every minute up to daily, depending on plan tier.

Will exporting Xero data affect my API rate limits?

Xero enforces 60 calls per minute per connected organisation, with 5 concurrent requests and a daily cap on top. A well-designed export tool stays well under that; incremental syncs typically only fetch records that changed since the last run, so the request count is small. If you're building a custom integration, you'll need to implement your own backoff and retry logic to stay under the limits. Sync tools handle this for you.

Need a current, queryable copy of your Xero data without writing a pipeline? Codeless Sync has a free tier, no credit card required. For the build-vs-buy decision in more depth, see Xero API vs Database Sync.

Related:

How to Design a PostgreSQL Schema for Stripe Data

ilshaad — Tue, 14 Jul 2026 16:27:09 +0000

Design a PostgreSQL schema for Stripe data: convert unix timestamps, store amounts in integer minor units, use a JSONB catch-all, and survive API drift.

By Ilshaad Kheerdali · 14 July 2026

Once you have decided to get your Stripe data into PostgreSQL, the first practical question is what the tables should look like. The Stripe API returns tidy, self-describing JSON, so the obvious move is to create one column per field and call it done.

That obvious schema is a trap. The types in a Stripe payload lie to you (timestamps are integers, money is integers, half the interesting fields are nested objects), the payload shape changes as Stripe evolves its API, and a table built from one example payload gives you no plan for what happens on the second sync when the same customer comes back with new values.

This post walks through the three type traps, why the flat one-column-per-field dump ages badly, and the schema pattern that holds up in production. If you want to see finished schemas first, the free Stripe to Postgres Schema tool shows the exact production table for 9 core Stripe objects, side by side with the naive dump so the differences are obvious.

The three type traps in Stripe JSON

Timestamps are unix epoch integers

Every timestamp Stripe sends is epoch seconds: "created": 1782950400. Dump that into a BIGINT column and every date query you ever write needs a conversion wrapped around it. Convert once at insert time instead, with PostgreSQL's to_timestamp(), and store a TIMESTAMPTZ:

-- Once, at insert time:
to_timestamp(1782950400)  -- 2026-07-02 00:00:00+00

-- Forever after, plain SQL just works:
SELECT count(*) FROM stripe_customers
WHERE created >= date_trunc('month', now());

Amounts are integers in minor units

Stripe represents money in the smallest currency unit to avoid floating-point rounding errors, so £29.99 arrives as 2999. Store it as an integer and divide by 100 for display. One exception is documented in Stripe's currency docs: zero-decimal currencies like JPY are already whole units. Stripe also supports a handful of three-decimal currencies like KWD, where the minor unit is 1/1000, so the divisor there is 1000.

The trap is not the storage, it is the reading. An amount column holding 2999 looks like two thousand pounds to anyone querying it cold. Keep amounts as integers (never REAL or FLOAT), and make the minor-units convention loud in your column comments and dashboards.

Nested objects do not flatten

address, invoice_settings, recurring, metadata: a good chunk of every Stripe payload is nested. Flattening them into columns explodes the column count, and dumping each one into its own JSONB column just gives you a pile of fragments. Neither gets you queryable data.

Why one column per JSON field ages badly

Beyond the type traps, the flat dump has three structural problems.

No upsert key. A schema generated from a payload gives you columns, not decisions. The decision that matters most is the primary key, because syncing is repetitive by nature: the same customer comes back on every sync with updated values. Without a primary key there is nothing to ON CONFLICT against, so re-syncs either duplicate rows or fail.

No indexes. The fields you will actually filter on (customer, status, created) get no indexes, so queries crawl as the table grows.

Schema drift. The Stripe API changes shape. In API version 2025-03-31 (basil), Stripe removed current_period_start and current_period_end from the Subscription object (they moved to subscription items), removed the paid boolean from invoices, and restructured invoice line items. A table generated from one payload is only correct for that payload, on that API version, on that day. When Stripe adds or moves a field, the flat dump breaks silently: new fields vanish, and inserts written against the old shape start failing.

The PostgreSQL schema pattern that works: curated columns plus a JSONB catch-all

Here is the actual production table for Stripe customers (this is the template Codeless Sync auto-creates, shown verbatim in the schema tool):

CREATE TABLE IF NOT EXISTS stripe_customers (
  -- Core queryable fields
  id TEXT PRIMARY KEY,
  email TEXT,
  name TEXT,
  description TEXT,
  currency TEXT,
  balance INTEGER DEFAULT 0,
  delinquent BOOLEAN DEFAULT false,

  -- Full payload
  data JSONB,

  -- Sync metadata
  livemode BOOLEAN NOT NULL,
  created TIMESTAMPTZ NOT NULL,
  synced_at TIMESTAMPTZ DEFAULT NOW() NOT NULL
);

CREATE INDEX IF NOT EXISTS idx_stripe_customers_email ON stripe_customers(email);
CREATE INDEX IF NOT EXISTS idx_stripe_customers_created ON stripe_customers(created);
CREATE INDEX IF NOT EXISTS idx_stripe_customers_livemode ON stripe_customers(livemode);
CREATE INDEX IF NOT EXISTS idx_stripe_customers_delinquent ON stripe_customers(delinquent);

Four deliberate choices are doing the work:

A short set of typed, queryable columns. Only the fields you filter, join, and report on. Timestamps are already TIMESTAMPTZ, amounts are integers, and everything has a real type instead of a guess.
A data JSONB catch-all holding the full payload. Nothing is ever lost, and this is the drift insurance: when Stripe adds a field next quarter, it lands inside data instead of breaking your inserts. You can query it any time with data->>'phone'.
Sync metadata. livemode keeps test and live records separable, and synced_at tells you how fresh every row is, which is the first thing you check when a number looks off.
Indexes on the fields you actually query. Email lookups, date ranges, and delinquency filters stay fast at any table size.

Pick the upsert key before the first insert

Stripe IDs (cus_..., in_..., sub_...) are stable, unique text values, which makes them the natural primary key. With id TEXT PRIMARY KEY in place, re-syncing is one idempotent statement:

INSERT INTO stripe_customers (id, email, name, currency, balance, delinquent, data, livemode, created)
VALUES ($1, $2, $3, $4, $5, $6, $7, $8, to_timestamp($9))
ON CONFLICT (id) DO UPDATE SET
  email      = EXCLUDED.email,
  name       = EXCLUDED.name,
  balance    = EXCLUDED.balance,
  delinquent = EXCLUDED.delinquent,
  data       = EXCLUDED.data,
  synced_at  = NOW();

Run it once or a thousand times, the table stays correct. This is the single decision the flat dump never makes for you, and it is why re-syncs against naive schemas end in duplicate rows.

For joins, the reference fields do the same job across tables: stripe_invoices.customer points at stripe_customers.id, stripe_subscriptions.customer likewise. One table per Stripe object, joined on IDs, and metrics queries like the ones in how to calculate MRR, churn, and LTV in PostgreSQL fall out naturally.

Schema drift is the part nobody budgets for

Designing the schema is a one-off. Keeping it correct is not, and this is the cost that surprises teams months later.

Stripe versions its API and moves fields between objects, as the basil changes above show. Your own usage changes too: the day you need subscription analytics, you need the subscriptions and subscription items tables you did not create on day one. And every change lands on you as migration work: alter the table, backfill the column, update the insert code, re-test the sync. It is exactly the kind of recurring, unglamorous maintenance that quietly breaks Stripe-to-Postgres pipelines.

You can absolutely own that chore yourself, and if you are hand-building, this post's pattern (curated columns, JSONB catch-all, upsert key, sync metadata) minimises it, because unknown fields flow into data instead of breaking the pipeline.

The alternative is to not own it at all. Codeless Sync creates these exact tables in one click and keeps them filled on a schedule (hourly, daily, or custom cron on paid tiers), with full and incremental sync modes, timestamps converted, amounts kept in minor units, and the complete payload preserved in data. There are no webhooks or cron jobs to babysit and no drift handling on your plate. The 5-minute walkthrough is in how to sync Stripe data to PostgreSQL, and if you are still weighing approaches, 5 ways to get Stripe data into PostgreSQL compares the options honestly.

Either way, start from the right schema. All nine production templates (customers, invoices, subscriptions, payment intents, products, prices, refunds, invoice line items, subscription items) are free to inspect and copy in the Stripe to Postgres Schema tool.

Frequently Asked Questions

Should I store the whole Stripe payload in one JSONB column?

Not on its own. A single JSONB column preserves everything but makes every query a JSON-path expression, indexes get awkward, and type safety disappears. The hybrid works better: a handful of typed columns for the fields you query, plus one data JSONB column holding the full payload for everything else. You get fast, readable SQL and lose nothing.

Should Stripe amounts be INTEGER, BIGINT, or NUMERIC in PostgreSQL?

Use an integer type and keep Stripe's minor units. INTEGER covers single-object amounts comfortably (its ceiling is over 21 million pounds in pence), and BIGINT is the safe pick for aggregates or if you would rather never think about the ceiling. Avoid REAL and FLOAT entirely for money, and only convert to NUMERIC at display or reporting time when you divide by 100 (or 1000 for three-decimal currencies).

How do I store Stripe metadata in PostgreSQL?

As JSONB. Stripe's metadata object is arbitrary user-defined keys, so it has no fixed shape to model as columns. Query it with data->'metadata'->>'your_key', and if you filter on metadata often, add a GIN index on the JSONB column or an expression index on the specific key you query.

Do I need a separate table for every Stripe object?

Yes, one table per object type: customers, invoices, subscriptions, payment intents, and so on. Stripe objects reference each other by ID, so separate tables joined on those IDs (for example stripe_invoices.customer to stripe_customers.id) mirror the API's own structure and keep queries simple. The schema tool shows the table for each of the 9 core objects.

How do I keep my Stripe tables up to date when the API changes?

Three habits if you are hand-rolling: pin your Stripe API version so changes only arrive when you choose, watch the Stripe API changelog for moved or removed fields, and keep a full-payload JSONB column so new fields are captured even before you model them. Or hand the chore off entirely: a managed sync like Codeless Sync owns the schema, the conversions, and the drift handling, so your tables stay current without migration work.

Related:

Xero API vs Database Sync: Which is Better?

ilshaad — Mon, 06 Jul 2026 14:11:03 +0000

Xero API vs database sync for getting accounting data into PostgreSQL: a build-vs-buy guide covering OAuth tokens, rate limits, and the real maintenance cost.

By Ilshaad Kheerdali · 6 July 2026

If you're building on top of Xero, you'll eventually need that accounting data in your own database, to power dashboards, reconcile revenue, or join it against your product tables. There are two ways to get it there: build your own integration against the Xero API, or hand the job to a managed database sync. Both work, but they cost you very different things.

It helps to be honest about the framing first. This isn't really "API versus no API", because a managed sync uses the Xero API under the hood too. The real question is build versus buy: do you own the OAuth tokens, the tenant routing, the pagination, the rate-limit backoff, and the schema mapping yourself, or do you let a service run all of that for you? This post compares the two at decision altitude. (If you just want the step-by-step setup instead, here is how to sync Xero to PostgreSQL in five minutes.)

How a Xero API Integration Works

Building your own integration means going directly to Xero's developer platform. The shape of the work is always the same:

Register an app in the Xero Developer portal and get your client credentials.
Send each customer through the OAuth 2.0 consent flow with the offline_access scope, then store the access and refresh tokens. Because one Xero login can cover several companies, you also call the Connections endpoint and keep track of each tenantId.
Poll the Accounting API for the objects you care about (invoices, contacts, payments, and so on), paging through the results and sending the right Xero-tenant-id header on every call.
Map each object shape into your own tables, and keep refreshing tokens so the connection never goes stale.

In code, the loop you end up owning looks something like this:

// The moving parts you operate yourself, on every connected organisation, forever
const accessToken = await refreshIfExpired(org.tenantId); // 30-minute access tokens
const invoices = await pageThrough('/Invoices', accessToken, org.tenantId); // 100 per page

for (const invoice of invoices) {
  await upsertIntoPostgres(invoice); // your mapping, your schema
}

// plus: refresh-token rotation, 429 backoff, per-tenant scheduling, and schema drift

That snippet hides a lot. The OAuth handshake, the tenant enumeration, the pagination, and the incremental fetching are each a small project of their own. The point here is narrower: what does that integration cost you after it ships?

The Hidden Costs of Rolling Your Own

The first version is the fun part. The cost shows up later, in the things you have to keep running:

OAuth tokens you babysit forever. Access tokens last 30 minutes, so you are refreshing constantly. The refresh token has a rolling 60-day life, but it is single-use: every refresh returns a brand new refresh token and invalidates the old one, so you must persist the newest value every single time. Store the wrong one and you get a dead connection that only a manual reconnect can fix. Let a connection sit idle past 60 days and it expires too.

Rate limits you engineer around. Xero throttles each connected organisation to 60 calls per minute, with only 5 requests allowed in flight at once and a further daily cap, on top of a 10,000-per-minute ceiling across your whole app. Cross a line and you get an HTTP 429 with a Retry-After header, then you back off and retry. With one client that is trivial. Across dozens of connected organisations, throttling becomes its own scheduling problem.

List calls hide the detail you actually need. Ask Xero for a list of invoices and it returns a trimmed summary with no line items, to keep the response fast. To get the full record you either fetch each invoice individually or page through with the pageSize parameter (100 per page by default, up to 1000). So a single "get my invoices" is rarely one call, it's many.

Incremental sync that quietly misses changes. The efficient way to pull only what changed is the If-Modified-Since header, which filters on each record's UpdatedDateUTC. The catch is that some changes never bump that timestamp, including a contact's outstanding balance and its customer or supplier flags. A naive incremental sync slowly drifts out of date, so you still need a periodic full reconciliation to stay honest.

Webhooks cover almost nothing. If you were hoping to skip polling, Xero webhooks only fire for four things: contacts, invoices, credit notes, and Xero App Store subscriptions. There is nothing for accounts, payments, bank transactions, items, or journals. They emit create and update events only (a deletion or void arrives, if at all, as an update), and the payload carries just a reference, the resource id and URL, not the data itself, so you still call the API to fetch the actual record. Undelivered events are retried and stored for around 31 days, which means idempotency and replay handling are yours to build.

Schema mapping across many objects, and it moves. Invoices, contacts, accounts, bank transactions, credit notes, items, purchase orders, and journals each carry their own shape and their own relationships. You map every one of them into tables, and when Xero changes a payload, you update the mapping.

How Database Sync Works

Database sync takes the opposite approach. Instead of you operating a pipeline against the Xero API, a managed service does the pulling and writes the results straight into your PostgreSQL database.

The flow looks like this:

Connect your PostgreSQL database (Supabase, Neon, Railway, AWS RDS, or any PostgreSQL host)
Authorize Xero once through the standard consent flow, and pick which organisation to sync
The sync service calls the Xero API for you, pages through the data, and writes structured tables
On every later run it pulls what changed and upserts, so there are no duplicates and no gaps

There is no Xero app to register, no refresh-token rotation to schedule, no 429 backoff to code, and no tenant headers to juggle. The accounting data simply shows up in your database, ready to query.

Side-by-Side Comparison

Factor	Build It Yourself (Xero API)	Managed Database Sync
Time to first data	Days to weeks: app, OAuth, tenants, paging, schema	About 5 minutes: connect database, authorize
OAuth token lifecycle	Yours to run: 30-min access, 60-day rolling single-use refresh	Handled for you
Multi-organisation	You enumerate tenants and route every call	Pick an organisation and sync it
Rate-limit handling	You build it: 60/min per org, 5 concurrent, 429 backoff	Managed by the service
Historical backfill	You write paginated backfill	Full backfill on first sync
Incremental updates	You track `UpdatedDateUTC` and its blind spots	Pulls changes and upserts every run
Schema mapping	You map every object and track payload changes	Tables auto-created and maintained
Data freshness	On-demand; near real-time for the 4 webhook objects	Batch (scheduled, e.g. hourly or daily)
Control & customization	Full: fields, transforms, write-back	Standard tables, less custom
Total cost of ownership	Build plus perpetual maintenance	Predictable flat subscription

When to Build It Yourself

Rolling your own is the right call in a few real cases:

You need write-back. Sync tools are read-only by design. If you have to create or update records inside Xero, like raising invoices or adding contacts, you need the API directly.
You need real-time reaction to one of the few events Xero actually pushes, such as a new invoice or contact, rather than a scheduled batch.
You have unusual object or field requirements that a standard sync does not cover.
You already run pipeline infrastructure, so the marginal cost of one more integration is genuinely low.
You want full control over every transform and mapping, and you are willing to maintain it.

If that sounds like you, build it directly against the API and budget for the upkeep above. The control is real, and so is the maintenance.

When to Use Managed Sync

Managed sync is the right call when you mainly want to query the data, not operate a pipeline:

Build dashboards and reporting on revenue, cash flow, or accounts payable and receivable
Run ad-hoc SQL against your accounting data, like "which suppliers are we due to pay this week?"
Join Xero data with your own tables, matching invoices or contacts to your app's users
Keep maintenance near zero, with no token rotation, rate-limit code, or reconciliation job to own
Pay a predictable flat cost instead of perpetual engineer time

Once your data is in Postgres, a question like "what are we owed, and what do we owe?" is just SQL:

-- Net position from xero_invoices: sales owed to you vs bills you owe
SELECT
  type,                                     -- ACCREC = sales invoices, ACCPAY = bills
  COUNT(*) FILTER (WHERE amount_due > 0) AS open_invoices,
  SUM(amount_due) AS outstanding
FROM xero_invoices
WHERE status IN ('AUTHORISED', 'SUBMITTED')
GROUP BY type;

Try doing that against the Xero API directly. You would need paginated calls per organisation, client-side filtering, and careful rate-limit handling. With synced data, it's one query. If you would rather not build any of the pipeline, here is how to sync Xero data to PostgreSQL automatically.

When to Use Both

These two approaches are not mutually exclusive, and the strongest setups use both:

The Xero API (or a webhook) for the few moments you need to react instantly, like flagging a large invoice the second it's approved
Managed sync for the queryable, reconciled copy your team runs reports against

Your app reacts to the events that genuinely need real-time handling, while your team runs any query it likes against the synced database. The common mistake is building and maintaining a whole custom integration just to power dashboards that never needed sub-minute freshness, then paying for that decision in token refreshes, 429 retries, and reconciliation jobs for years.

Getting Started with Database Sync

If you'd rather not build and babysit all of that, Codeless Sync connects your PostgreSQL database and syncs Xero data, contacts, invoices, payments, accounts, bank transactions, credit notes, items, purchase orders, journals, and organisation details, in about 5 minutes. It handles the OAuth consent and token refresh for you, lets you pick which organisation to sync, auto-creates the destination tables, and upserts on every run so there are no duplicates. There's a free tier, no credit card required.

The same model works for Stripe, QuickBooks, and Paddle too, so if your finances span more than one provider, all of it lands in the same Postgres database. You can point it at Supabase, Neon, Railway, or AWS RDS, whichever host you already use.

Frequently Asked Questions

Should I build my own Xero integration or use a sync tool?

Build it if you need to write data back into Xero, want real-time reaction to specific events, or already run pipeline infrastructure. Use a sync tool if you mainly need a queryable copy of your accounting data for dashboards, reporting, or reconciliation, and you would rather not own OAuth token rotation, tenant routing, and rate-limit handling. Plenty of teams do both: the API for the few real-time events, managed sync for everything else.

What does it actually cost to maintain a Xero API integration?

The code is a one-time build. The cost is everything after: rotating the single-use refresh token on every refresh before the 60-day window lapses, backing off when you hit the 60-calls-per-minute or 5-concurrent limit on each organisation, running a periodic reconciliation for changes that don't bump UpdatedDateUTC, and updating your mapping when Xero changes a payload. That is recurring engineer time, which is what a flat-rate managed sync is really replacing.

Does a managed Xero sync still use the Xero API?

Yes. A sync tool like Codeless Sync talks to the same OAuth 2.0 and Accounting API endpoints under the hood. The difference is that it operates the consent flow, the tenant selection, the pagination, and the schema mapping for you, so what you end up with is a set of PostgreSQL tables to query rather than a pipeline to maintain.

Can Xero webhooks replace a scheduled sync?

Not for analytics. Xero webhooks only fire for contacts, invoices, credit notes, and App Store subscriptions, emit create and update events only (no deletes), and carry just a reference rather than the record itself, so you still call the API to fetch the data. For a complete, queryable copy of your accounting data, a scheduled sync is more reliable and needs no public endpoint. Use webhooks only for the specific events you must react to the instant they happen.

Which Xero data can I sync to my database?

Codeless Sync supports ten Xero data types: contacts, invoices, payments, accounts, bank transactions, credit notes, items, purchase orders, journals, and organisation details, each written to its own PostgreSQL table. After the first full pull, later runs are incremental, so each sync only brings over what changed.

Related: