Accepting a new integration: the order in which to test it before you trust it

1. The result and its owner

Write one sentence saying what is true afterwards, who owns the account at the provider and who accepts the change. Everything below tests that sentence. If two people would describe the result differently, stop and settle it before any code is written.

• One result per integration.
• A named person for the provider account.
• A named person to accept.

2. Credentials and where they live

Decide which credential the connection uses, its permissions, who creates it and where it is stored. Use restricted staging credentials for development and keep the production credential in your secret store. Record the kind of credential and any date the provider shows in the register, without the secret itself.

• Narrowest permission that works.
• Separate staging and production.
• Nothing in the repository, logs or an enquiry.

3. The test route and its limits

Establish how the connection can be tested safely: a sandbox, a test mode, a test channel or mailbox, a stand-in service. Then write down what that route cannot show. Twilio's test credentials, for example, produce no status callbacks, so delivery tracking needs a live send to a phone you own. Choose what is tested where.

• Test channel, mailbox or phone you own.
• A stand-in for failure cases you cannot cause at the provider.
• Never test on real customers.

4. The happy path, end to end

Run the agreed event through the whole path and compare the visible result with the sentence from step 1: the message arrived, the event is on the calendar, the lead is in the CRM, the file is stored. Keep a dated record of what you saw. Then run it a second time with the same input and see that nothing doubled.

• Record the evidence in a form you can inspect later.
• Include a case in another time zone or character set where relevant.
• Check the repeat before moving on.

5. Failure paths

With the stand-in or the provider's documented error values, make the connection fail in each way that matters: the provider is down, it limits requests, it rejects the credential, it is slow. The customer's action should succeed, the failure should be visible to a person and no duplicate should appear. Test the credential lapsing as well, because it will eventually.

• Rate limit with a wait.
• Rejected credential.
• Timeout on a write.

6. Inbound requests, retries and write safety

If the provider calls you, verify each request on the raw body and enforce any timestamp window, reply inside the time limit and process each event once. If you call the provider, set out the retry policy in writing and make sure a retried write cannot duplicate. The guides and the worked examples linked here cover both directions.

• Signature, timestamp and event ID.
• Attempts, waits and total time.
• Identifier or lookup for every write.

7. Monitoring and the next owner

Before you call it finished, decide who will notice if it breaks and when credentials or quotas will be reviewed. For several integrations, one internal module and a register make that practical; the consolidation project and the monthly integration-health service exist for those cases, at untested prices of from £3,500 after a quote and a fixed £195 a month. Payment follows agreed checks and sign-off. A single connection can stop at step 6 if one person owns the register.