An API integration connects systems, but the business requirement is usually more specific: move the right information at the right time without losing or duplicating work. Describe that outcome before discussing middleware or custom code.
Map the data and its owner
List the source system, destination system, trigger and fields that must move. Identify which system is authoritative when records disagree. Decide how deleted, changed or incomplete records are handled.
For example, sending an approved customer record to a billing tool is different from synchronising every contact in both directions. The second requirement creates more conflict and permission decisions.
Specify failure behaviour
Ask the specialist to distinguish a temporary outage from an invalid record. Temporary failures may be retried; invalid records usually need a person to correct something. Both should be visible to an operator.
Require protection against repeated delivery. A retry must not create a second order or duplicate invoice. Include limits imposed by each provider, and define how the integration catches up after downtime.
Review access and acceptance
Use separate application credentials with the narrow permissions required. Agree on who owns them and how they can be rotated. Keep credentials out of client-side code and public logs.
Acceptance should include a normal transfer, an update, a duplicate event, a rejected record and a provider outage. Ask for a reconciliation view showing what was sent and what is still pending.
The OWASP API Security project is a useful reference for the security review. For delivery, require a field map, test results, operating notes and named support responsibility. Browse integration developers with these requirements rather than a vague request to “connect the apps.”