Reliable Software Integrations: A Guide to Systems That Keep Working

An integration is not complete when two systems exchange one successful test record. It is complete when people can understand, operate and correct the connection through normal change, incomplete data and temporary failures.

Reliable integrations begin with a modest claim: move a specific piece of information for a specific purpose, with a named owner on each side.

Define the contract before the connector

For every important field, state where it originates, who may change it, when it moves and how it is identified. A customer record, job, invoice or user account needs a stable identifier; names alone are not dependable matching keys.

Also decide the direction. “Sync everything both ways” is often a request for ambiguity. Prefer one system being authoritative for each category of data, even if information is displayed in several places.

Design for ordinary failure

Networks time out, APIs impose limits, and people enter incomplete records. A dependable integration makes these events visible rather than silently dropping data.

• Retry safe operations with a bounded policy.
• Prevent duplicates with idempotent identifiers or a recorded transfer state.
• Keep a readable failure queue with the affected record, reason and next action.
• Alert the team only when a person needs to act.
• Record enough history to reconcile what moved and what did not.

The right level of engineering depends on the workflow. A nightly reporting export and a payment-status update have different consequences when delayed. State that consequence explicitly.

Keep changes survivable

Third-party systems change fields, permissions, API versions and rate limits. Store credentials securely, document the integration's assumptions, and make ownership part of the operating plan. A connection that only one contractor can inspect is a business risk.

Illustrative example: a job platform may send approved job data to an accounting platform once per hour. If one record fails validation, a coordinator could correct it in the source system and retry that record. This example describes a possible operating pattern; it is not a client case study or a promise of suitability.

A practical discovery checklist

1. Name the user outcome the integration supports.
2. Map the source, destination and authoritative owner for each field.
3. List the expected volume, timing and acceptable delay.
4. Describe duplicate, conflict and failure handling.
5. Identify who monitors and corrects exceptions.
6. Test one end-to-end flow before expanding the scope.

Accounting-related flows benefit from the build-or-integrate accounting guide. For a broader decision on whether to create a custom layer at all, read when custom software is worth building.

Choose the smallest dependable connection

The goal is not to connect every system. It is to remove one costly or risky hand-off without replacing clear human judgement with invisible automation. Start with the flow that can be measured, operated and reconciled.

If you are assessing an integration for a Geelong team, capture the source, destination and repeated problem in a project brief. We can help frame the first technical and operational questions.