A quote entered in one tool, copied into the invoicing software, then reported in a tracking spreadsheet. Every re-entry takes time and eventually produces an error. Most organisations that contact me do not need new software: they need the tools they already use to talk to each other.
This article explains the three ways to make software communicate, how to choose between them and what a reliable integration must plan for. It is written for SMEs, nonprofits and local authorities, with no technical background required.
In short
There are three ways to connect business software: file exchange (CSV or Excel export, then import), a no-code connector (Zapier, Make, n8n) and a custom API integration. Export is enough for an occasional exchange. A connector suits simple flows between mainstream tools. A custom API integration is the right choice when business rules, volumes or reliability become critical.
- Before choosing: check that each tool offers a documented API, and on which subscription plan.
- The real question: which tool is the source of truth for each piece of data, and what happens when an exchange fails.
- The trap: a sync that fails silently is worse than manual re-entry.
What is an API, in practice, for an SME or a nonprofit?
An API is an entry point a piece of software opens so that other programs can read or change its data without going through the screen. Instead of exporting a file and importing it elsewhere, a program asks directly “give me today’s invoices” and receives a structured answer, usually in JSON.
For an organisation, it means information entered once can flow automatically: a member who signs up on the website appears in the management tool, a confirmed order creates the invoice, a closed case updates the dashboard. The API does nothing on its own: a program, a connector or a development is needed to use it.
File export, no-code connector or custom API: which one to choose?
The right choice depends on how often data is exchanged, the volume, how complex the rules are and what an error costs. The table below sums up where each option works well.
| Option | Works well when | Limits |
|---|---|---|
| File export / import | The exchange is occasional (monthly, yearly) and someone checks the file | Manual, prone to format errors, no automatic trace |
| No-code connector | Both tools are supported by the connector and the rule fits in a few steps | Priced by volume of operations, logic hard to review, dependency on the service |
| Custom API integration | Business rules are specific, volumes are large or an error is expensive | Initial development, plus maintenance when the tools evolve |
The options are not mutually exclusive. A connector can serve as a prototype to validate a flow for a few weeks, before it is rebuilt as a development once the rules settle. Conversely, building a custom API integration for a quarterly export is rarely justified.
How do you know if a piece of software has an API?
Look in the software’s documentation or footer for “API”, “developers”, “integrations” or “webhooks”. A serious vendor publishes documentation, often in OpenAPI format, listing the data available and the actions allowed. If nothing is public, ask support.
Before committing, check four points:
- Subscription plan: API access is sometimes restricted to higher tiers.
- Scope: does the API expose the data you need, for both reading and writing?
- Rate limits: a per-minute or per-day quota can block a high-volume sync.
- Webhooks: can the software notify other tools when data changes, or do you have to poll it regularly?
If a tool has no API, options sometimes remain: a scheduled automatic export, direct database access or structured emails. They work, but they are more fragile: they break without warning when the vendor changes its format.
Real-time or batch synchronisation?
Real time is only useful if someone is waiting for the information within the minute. For most management flows, a batch sync every hour or every night is simpler, cheaper and easier to monitor.
- Real time (webhook): the source software notifies as soon as data changes. Useful for a registration to confirm, a payment, a field alert.
- Batch (scheduled): a program fetches everything that changed since the last run at a fixed time. Suited to statistics, accounting and dashboards.
In both cases, decide which tool is the source of truth for each piece of data. If a client’s name can be edited in two tools, which one wins in a conflict? Without that written rule, the data drifts apart within weeks.
What happens when a sync fails?
It should report the failure, retry, then leave a usable trace. An exchange that fails silently is the most expensive flaw in an integration: weeks later you find invoices or registrations missing, without knowing which ones.
A reliable integration plans for:
- retries spaced out when the remote service is unavailable;
- idempotent exchanges: replaying the same message twice must not create two invoices;
- a log showing which data was sent, when and with what result;
- an alert sent to a named person when errors pile up;
- a failure queue that can be inspected and replayed after a fix.
With Symfony, these needs are covered by standard components: HttpClient to call APIs, Messenger for the queue, retries and the failure transport, Scheduler for planned syncs. The infrastructure is not reinvented; the work goes into the business rules. The Symfony API development page describes this approach.
What precautions for security and personal data?
Every connection between two tools opens access to your data. It should therefore have rights limited to what is strictly needed, credentials stored outside the code and a clear list of the personal data that flows through it.
- create a dedicated account or API key for each integration, with only the rights it needs;
- store keys in a secrets vault, never in code or a shared spreadsheet;
- transfer only the fields needed, especially for personal data;
- check where third-party services are hosted and list them in your GDPR record of processing;
- plan how to revoke access if a tool is dropped.
How do you scope an integration project?
By describing the flows before talking about technology. An integration brief often fits on two pages and answers five questions: which data flows, in which direction, how often, which tool is the source of truth, and who is notified when something fails.
- List the tools and current re-entries, with the time they take.
- For each flow, note the source, destination, frequency and volume.
- Map the fields: is a “client” in one tool a “contact” or an “organisation” in the other?
- Describe error cases: duplicate, missing field, service unavailable.
- Name the person who monitors and decides.
This work is very close to scoping a business application. The article on the questions to ask before replacing Excel offers a similar method.
Example: connecting several data sources in PictoRecette
PictoRecette is a Symfony application that produces recipe sheets illustrated with pictograms for cooking workshops. It relies on several external sources: ARASAAC pictograms, Open Food Facts product data and recipe sources.
The workflow chains several operations: fetch the information, normalise it, match it with a pictogram, then have a professional validate it before the PDF export. It is a typical case: automation does the repetitive work, and people keep control of validation. A good integration does not remove control; it removes re-entry.
FAQ
Is a no-code connector enough for a small organisation?
Often, yes, for simple flows between mainstream tools. It becomes limiting when rules multiply, when volume-based pricing climbs or when nobody can read the scenarios any more. That is the signal to move to a development.
Can you connect an old tool that has no API?
Sometimes, through a scheduled export, access to its database or an intermediate API built around it. It is more fragile than an official API and needs closer monitoring.
Who maintains the integration when a tool changes?
Decide it from the start. Vendors evolve their APIs and announce the end of older versions. An integration needs an owner and a maintenance agreement, even a light one.
Should you build your own API?
Only if your application needs to be read or fed by other tools. For a custom business application, planning an API from the start makes future connections easier. The article on Symfony and API Platform for a business application covers this choice.
Conclusion
Connecting business software does not start with choosing a tool, but with listing real re-entries and flows. Export is enough for the occasional, a connector for the simple, a custom API integration for what must be reliable and follow your rules. In every case, an integration must report its errors.
If your teams copy the same information from one tool to another, describe your tools and flows: together we can identify what is worth automating, and what is not.