A practical integration checklist

Checklists have a reputation problem. They are associated with compliance, not judgment. In practice, a short checklist is what stops a competent person from forgetting a boring detail at eleven at night.

This is the list I have built up for integrations, especially the ones that move money or customer data between systems that were designed separately.

Before you design anything#

Most integration problems are decided before the first line of code is written. The questions worth answering early are about ownership and expectations:

• Which system is the source of truth for each field?
• Who is allowed to change a value, and who is notified when it changes?
• What is the realistic volume, and what is the peak?
• What is the acceptable delay between an event and its downstream effect?
• What should happen if the integration is unavailable for an hour? For a day?

If two systems both believe they own the same field, the integration will eventually disagree with itself. Better to find that out during design.

The contract#

The interface contract is where most of the practical risk lives. I keep a short table of questions for every integration.

The table is not exhaustive. It is a prompt to stop assuming.

Before go-live#

The tests below are the ones that have caught real problems. They are not replacements for a proper test suite; they are the awkward cases that suites tend to skip.

1. Send a malformed request on purpose. Confirm the error is useful, and that it does not leak sensitive details.
2. Replay a successful write. Confirm the receiving system does not create a duplicate.
3. Run with an expired credential. Confirm the failure is clear and recoverable.
4. Test the daylight-saving boundary. A request made at 01:30 on the transition day should not land on the wrong day.
5. Send the largest realistic file. Not the sample. The one that is ten times bigger than the specification implies.
6. Trace one request end to end. Confirm both sides log the same correlation id.
7. Write the rollback before you need it. Know how to stop the flow, and what happens to the data already in flight.

A correlation id is worth more than a dashboard during the first incident. It should be generated by the caller, logged on both sides, and included in every support ticket.

curl -X POST https://api.example.com/v1/invoices \
  -H "Authorization: Bearer $TOKEN" \
  -H "Idempotency-Key: 01J9Z6W4K2" \
  -H "X-Correlation-Id: impl-2026-07-12-0007" \
  -H "Content-Type: application/json" \
  -d @invoice.json

After go-live#

The first day is not the end of the project. A short window of deliberate attention catches the failures that only appear under real data:

• Watch the error rate, not just the success rate.
• Confirm that retries are not quietly creating duplicates.
• Check the credential rotation date and put it somewhere people will see it.
• Ask the operations team what they would need if this broke at 2am.

That last question is usually the most revealing one.

The checklist is not the point#

The checklist is a way of making assumptions visible. The actual skill is knowing which assumption matters most for this integration, and testing that one first.

A checklist that is followed blindly is no better than no checklist at all. One that is short enough to be used, and specific enough to be uncomfortable, is worth keeping.