This task is one section of Eight software practices that keep business apps reliable, with 7 related tasks on one page.
1. Name one operation
Write the record you will create or read, the address, and the fields you send. Do not start by syncing every object the other system offers.
2. Keep the secret out of logs
Store the key in the place your host provides for secrets. Logs and error messages should show a request id, not the key.
3. Prove a success
Send one call that should work. The other system should show the record, and your system should store the other side’s id.
4. Prove a rejection
Send one call with a missing required field. Your user should see a clear failure, and you should be able to try again without creating a duplicate.
5. Frequently asked questions
Should I import the whole history first?
No. Prove one record in each direction, then decide what history is worth moving.
What if the other system times out?
Record the timeout and whether it is safe to retry. A retry that creates a second order is a failed integration.
Do I put the key in the database?
Only in a secret store or an encrypted setting. Do not put it in source code or a ticket.
6. Related articles and next steps
Treat the checks below as the acceptance test for the change. Names of libraries can vary; the behavior to prove does not.