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

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: