Direct answer
Choose the exchange method by how quickly a change in one system must be visible in the other, and by what it costs you if a change is missed. If someone acts on the data within minutes, you need the source system to push changes to you. If a daily view is fine, a scheduled pull or file is simpler and easier to reason about. If the data moves rarely, a manual CSV import may be the honest answer. Whether a method is available at all depends on what the source system offers, which you confirm in the API readiness check before choosing.
The four ways
These are the patterns most business integrations use, in plain terms:
- Webhook or event push: the source system sends a message to your receiving address when something changes
- Scheduled pull (polling): your automation asks the source system on a schedule what is new or changed
- Scheduled batch or file: a group of records is exported and loaded together on a schedule
- Manual CSV: a person exports a file from one system and imports it into the other when needed
Decide by how fast a change must show
Ask what happens between the change and the moment the other system knows about it. A new enquiry that must be answered quickly is a different case from a monthly report. Write the need as a sentence in your own words, for example: someone acts on this record as soon as it changes, or someone reads this once a day. Do not write a target time you have not actually needed; a vague wish for real time tends to buy complexity you never use.
Decide by what the source system offers
The method you want is limited by what the source can do. Some systems can send change messages, some only answer questions, and some only export files. Check this in the source system's own documentation or with its owner instead of assuming. If the only option is a file export, the design follows from that. Nothing on this page implies that any particular product supports any particular method.
Decide by volume and cost of a missed change
A missed change is expensive when it means a lost customer, a wrong invoice or a shipment that goes out on stale data. It is cheap when the next scheduled run fixes it. High volume and low tolerance for misses push you towards event push plus a safety net. Low volume and high tolerance favour the simplest method you can keep running. Also consider who will maintain it: a method your team cannot inspect is a method that fails silently.
The hybrid: event signal plus periodic catch-up
Push messages can be lost, delayed or delivered twice, and a receiving address can be down when the message arrives. A common pattern is to use the event push for speed and add a periodic catch-up check that asks the source what changed since the last successful run and fills any gaps. The receiving side should also handle the same change arriving twice without creating a duplicate. This pattern does not guarantee that nothing is ever missed, but it turns a silent loss into something a later run can repair.
What each method does when it fails
Compare methods by their failure behaviour, not only by the happy path:
- Event push: a failed delivery may be retried or dropped depending on the source system; you need to find out which and plan for a gap
- Scheduled pull: a failed run leaves a gap that the next run can cover if it asks for everything since the last success
- Batch or file: a bad file can fail as a whole, so decide whether one bad record blocks the rest
- Manual CSV: it fails when nobody remembers to do it, so it needs an owner and a reminder
Decision guide
Use this as a starting point, then test it against your real case:
- Someone acts on the change soon after it happens and the source can push: event push plus catch-up
- A daily or weekly view is enough and the source can be queried: scheduled pull
- Large sets of records move together and file export is what the source offers: scheduled batch
- Rare, one-off or low-volume movement with a clear owner: manual CSV
- You cannot say what a missed change costs: settle that before choosing anything
Writing the choice into the specification
Record the decision where the build team and the next person will find it: the method, why it was chosen, what the source offers, how a failure is noticed, how gaps are filled and who owns the schedule. The system integration specification template has a place for each of these. Pair it with a system of record decision so it is clear which system wins when the two disagree.
Where LATYNEX fits
If you want help choosing and building the exchange, a small first integration can be scoped as the Automation Sprint (€1,690, fixed scope), agreed in writing before work starts. Larger or unusual integrations are scoped separately after a technical review of the systems involved. See Workflow Automation & Systems Integration.
Questions
Is a webhook always better than polling?+
No. An event push is faster, but it depends on what the source offers and needs a way to handle lost or repeated messages. A scheduled pull can be the more reliable choice when speed is not needed.
When is a manual CSV import acceptable?+
When data moves rarely, volume is low, a named person owns the task and a delay or slip does not cost much. Write down who does it and how they will remember.
Can I combine methods?+
Yes. Pairing an event push with a periodic catch-up check is a common approach, because the catch-up fills gaps the push missed.
Do all systems support webhooks?+
No. Check the source system's own documentation or ask its owner. Do not assume a method is available because another system offers it.
How do I know my choice was right?+
Compare the two systems on a schedule and note how often gaps appear and who noticed. The routine in the reconciliation guide gives you that evidence.