Every joined-up reporting or automation project rests on one question: will your existing software let another program read its data? The answer varies enormously, it's rarely on the marketing pages, and finding out late is what turns a three-week project into an argument.
The good news is that you can establish it yourself in an afternoon, with no technical knowledge, by asking a short list of questions. Here's the list, and what the answers mean.
The five levels of "talks to things"
| Level | What you have | What it means for you |
|---|---|---|
| 1 | A documented API with keys you can create yourself | Ideal. Hourly, reliable, no manual work. Most modern cloud software. |
| 2 | An API, but access is gated by the vendor or a partner programme | Workable, with a delay. Ask about timescales and cost early. |
| 3 | Scheduled exports (CSV to email, FTP or cloud storage) | Usable. Daily rather than hourly, and more fragile, but perfectly serviceable for reporting. |
| 4 | Manual export only, from a screen, by a person | Automatable only in part. Fine for a monthly figure; painful for anything weekly. |
| 5 | No export. Data only visible on screen. | Effectively a dead end. Either the process changes or the system does. |
Most small businesses find they're at level 1 for accounting and e-commerce, level 1 or 3 for industry-specific software, and occasionally level 5 for something old and load-bearing.
The questions to ask
Ask your own software, first
Look in Settings for any of: API, Integrations, Developer, Apps, Webhooks, Connections. If you can find a page that lets you generate an API key or token, you're at level 1 and most of your worries are over. Note whether you can create a read-only key — you want one, and their existence is a good sign of a well-designed system.
Then search for the documentation
Search for your software's name plus "API documentation". Public, current docs are a strong signal. A developer portal that needs an approval process means level 2 — still fine, but start the paperwork now rather than later.
Then ask support one specific question
Vague questions get vague answers. This one works: "Can I create a read-only API key to export our own data — orders, customers and invoices — to a system we control, on a schedule? Is there a rate limit, and does the API let me request only records changed since a given date?"
That last part is the question that separates a cheap integration from an expensive one, and almost nobody asks it.
If a system can tell you only "here is everything", then every refresh re-reads your whole history — slow, rate-limited, and often expensive. If it can answer "here is what changed since Tuesday at 14:00", refreshes are small and can run hourly forever. Same data, completely different project.
Finally, ask about push
Some systems can notify you the moment something happens — usually called webhooks. If yours can, near-real-time automations become possible: an order arrives, something happens straight away. If it can't, you poll on a schedule instead, and for almost all reporting purposes hourly is indistinguishable from instant. Don't pay extra for real-time you don't need.
Things that will bite you
Data you can read but not write. Very common, and often perfectly fine. It means reporting and alerting work, but "update the record automatically" doesn't. Establish which side of the line the thing you actually want falls on.
Rate limits. Most APIs cap requests per minute or per day. This matters only if the design ignores it. Ask the number and share it with whoever's building.
Per-connection charges. Some vendors charge for API access or for each connected app. Worth knowing before it's a surprise line on a renewal.
Whose account holds the keys. Keys should be created in your account, so you can revoke them the day you fall out with a supplier. If someone proposes creating them in theirs, that's a red flag about lock-in generally.
Custom fields. The most valuable data in a small business is often in a field somebody added by hand. Sometimes those come through the API; sometimes they don't. Check specifically for the ones you care about.
The spreadsheet that is secretly a system. Nearly every business has one workbook holding something essential that exists nowhere else. It's not a failure, but it needs naming early — it's usually easier to move that into a proper structure than to keep building around it.
What to write down
By the end of the afternoon you want a single page listing, for each system: what it holds that matters, its level from the table above, whether read-only keys are possible, whether it supports changed-since queries, and who in your business administers it. Most people are surprised twice — once by how much is possible, once by which one system is going to be the awkward one.
That page is also the thing that makes quoting honest. Any competent supplier can tell you what's feasible and what it costs in an hour if they have it, and will otherwise spend the first week of your project finding out — at your expense.
- System — and what it's the master of
- Level 1–5 from the table above
- Read-only key possible? Y/N
- Changed-since supported? Y/N
- Webhooks? Y/N — and whether you need them
- Rate limits / API charges
- Who administers it
Reading the answers you get back
Support desks answer integration questions badly, and not usually out of obstruction — the person replying often doesn't know. Four responses and what they actually mean.
"Yes, we have an API." Insufficient. Ask whether you can create a key yourself, whether it's read-only, and whether it covers the specific records you named. Plenty of systems have an API that exposes a fraction of what's on screen.
"You can export to CSV." Ask whether that export can be scheduled and delivered somewhere automatically, or whether it requires a person clicking a button. The difference decides whether you get hourly data or monthly data.
"That's available on our Enterprise plan." Get the number now. API access as a paid upgrade is common and legitimate, but it changes the arithmetic of the whole project, and it's much easier to discuss before you've committed.
"Why do you want to do that?" Sometimes genuine curiosity, sometimes the opening of a lock-in conversation. Answer plainly — you're consolidating reporting across systems. A supplier who's uncomfortable with that has told you something useful about them.
The single most efficient question: "Can you send me the link to your API documentation?" A public docs URL settles in thirty seconds what a support conversation takes a week to establish, and it lets whoever builds the thing check the specifics rather than relying on a summary.
Custom fields: the bit that catches people
The most valuable data in a small business is often in a field somebody added by hand — a category, a flag, an internal reference, the name of whoever looks after that account.
Whether those come through an API varies enormously. Some systems expose them cleanly. Some expose them with meaningless internal names like custom_field_7, which works but needs mapping. Some don't expose them at all.
So the audit question isn't "does it have an API" — it's "does the API return the three fields we actually care about". List those fields by name before asking. It takes two minutes and it's the difference between a project that answers your questions and one that answers adjacent ones.
What "read-only" really buys you
Worth being precise, because it's the answer to most of the anxiety about this kind of work.
A read-only key cannot create, change or delete anything. If the key leaks, the exposure is disclosure rather than damage — bad, but recoverable. If the integration has a bug, it produces wrong reports rather than wrong records in your accounts. And you can revoke it in one click without anyone's permission.
Some systems don't offer read-only keys, only full-access ones. That's a genuine risk worth naming rather than glossing over: it means anything reading your data could, in principle, write to it. Where that's the situation, the mitigations are to limit who holds the key, to log every call, and to be deliberate about whether the value justifies it.
Rate limits, in plain terms
Every API caps how often it can be called. The numbers look alarming and almost never matter, for one reason: an integration that asks only for what changed makes very few calls.
A system with a 60-calls-per-minute limit sounds restrictive. Fetching the twelve orders that changed in the last hour uses one or two of those calls. The same integration written naively — fetching all forty thousand orders every hour — would hit the ceiling immediately and get throttled.
So when you ask about rate limits, the answer matters less than pairing it with the changed-since question. Together they tell you whether hourly refreshes are trivial or impossible.
If something is at level 5
Occasionally a business depends on software with no way out. There are only three honest options, and it's better to choose deliberately than to drift: keep a manual step in the process and automate everything around it; change that system; or accept that this particular question won't be answered automatically. What doesn't work is pretending a workaround — screen-scraping a system that doesn't want to be read — is a stable foundation. It breaks at the worst possible moment, which is usually the week you've stopped keeping the manual version.