Integration Testing SOP

An integration testing SOP checks, before you build on top of them, that the payment, email, data and AI services your product depends on behave the way their marketing pages promise. One to two weeks of scripted calls in sandbox accounts shows you the rate limits, odd error codes and webhook surprises that otherwise appear on launch day. Your product is only as reliable as the weakest API it calls. You finish with a test log, a list of handled failures and a clear view of which vendors you can't afford to lose.

What is the integration testing SOP and when should you use it?

In this SOP, integration testing means calling each outside service from your own code, on purpose, in every way it can go right or wrong. You test sign-in to the API, data going in and coming back, every documented error, rate limits, timeouts and webhooks (messages the vendor sends to you when something happens). Developers also use the term for testing how internal modules fit together; this page focuses on the third-party connections a startup can't control.

Keep it separate from its neighbours. A proof of concept shows the whole idea works once. Technology stack validation picks your languages and frameworks. Business deals with partners belong in channel partner validation.

Use it:

• Before you commit to a vendor whose API sits at the heart of the product: payments, maps, AI models, bank data.
• When your idea is mostly glue between two or three platforms, such as an add-on for an online store.
• Before switching a sandbox account to live mode, since live behaviour differs.

What do you need before you start?

• A list of every outside service, including the small ones (email sending, address lookup, analytics).
• Sandbox or test accounts for each. Stripe test mode, PayPal sandbox and most email APIs offer one for free.
• The vendor docs open: the OpenAPI (formerly Swagger) spec if one exists, the rate limit page, the error code list and the webhook guide.
• Postman or a short script to send requests and save responses.
• A test log spreadsheet, set up before the first call.

How do you run it, step by step?

1. Map every connection and its job

Write one row per service: what you send, what you get back, how many calls per day, and what the customer sees if it fails. Mark each connection as blocking (the product stops without it) or degradable (the product still works, with less). Payments are blocking; a map preview is degradable.

2. Read the limits before you write code

For each vendor, copy into your log the documented rate limit, timeout, maximum payload size, sandbox differences, price per call and the deprecation policy. Limits you find now cost nothing; limits you find in production cost customers.

3. Script the happy path

Build a Postman collection or script that runs the normal flow end to end: create, read, update and delete the things your product touches. Check field formats on the way back: dates and time zones, currency in cents or units, character encoding for names like "Zoë" or "Łukasz".

4. Break it on purpose

Send wrong credentials, missing fields, oversized files and duplicate requests. Fire requests faster than the limit until you get HTTP 429 (Too Many Requests), and confirm your code waits for the Retry-After header and retries with exponential backoff and jitter, the pattern Marc Brooker describes on the AWS Architecture Blog. Use a mock server such as WireMock to simulate a vendor timing out or returning a 500 error.

5. Test webhooks as unreliable mail

Vendors send events late, twice or out of order; Stripe's webhook documentation says so and retries live-mode deliveries for up to three days. Verify the signature on every event, store event IDs to ignore duplicates, and send idempotency keys on payment requests so a retry never charges twice.

6. Measure the cost of each call

Record response times at the 50th and 95th percentile for each vendor, and add them up along the slowest user action. A page that calls three services one after another inherits all three delays.

7. Decide plan B for each blocking vendor

For every blocking service, write what happens if it disappears, triples its price or changes its terms: a second vendor, a cached fallback or a manual process. If you plan to keep several services in sync, add contract tests with Pact so a change on either side fails a test before it fails a customer.

Template you can copy

CONNECTION TEST LOG

Part A: Service map
Service | Job in product | Blocking / degradable | Auth type |
Rate limit | Timeout | Price per 1,000 calls | Sandbox Y/N |
Status page outages (last 90 days) | Plan B

Part B: Test cases (one row per test)
ID | Service | Scenario | Request | Expected result |
Actual result | Pass/Fail | Handler in code Y/N | Notes

Standard scenarios per service:
1. Happy path, full flow
2. Wrong or expired credentials (401/403)
3. Missing or malformed field (400/422)
4. Record not found (404)
5. Rate limit hit (429 + Retry-After)
6. Vendor error (500/503) via mock
7. Timeout over 10 s via mock
8. Duplicate request with idempotency token
9. Webhook: duplicate, late, out of order, bad signature
10. Special characters, time zones, currencies

Part C: Response times
Service | p50 ms | p95 ms | Calls per user action | Added to slowest action

Worked example: an inventory sync tool for small online shops

This is an illustrative case. A solo founder plans a tool that syncs stock levels between an online store platform, a marketplace and an accounting app. She sets up sandbox accounts for all three and runs 1,200 scripted test calls over eight days.

The log shows a 96.4% success rate, below her 99% bar. The failures cluster in three places. The marketplace API allows 2 requests per second, so a 3,000-product first import hits HTTP 429 within seconds; her first draft had no retry logic. The accounting app returns dates in UTC while the store sends local time, which shifts late-evening orders to the wrong day. Webhooks from the store arrive twice for 3% of orders, which would have double-counted stock.

She adds a queue that respects the rate limit, converts all dates to UTC on arrival and stores event IDs to drop duplicates. The rerun hits 99.6%, and the remaining failures are mocked vendor outages that now show a clear "sync paused" message.

What should you measure, and when do you stop?

Stop when two consecutive full runs pass every scenario and the plan B column has no blanks. Rerun the suite before each vendor version change and before switching to live mode.

Which mistakes should you avoid?

• Testing only the happy path. Vendors fail in ways their demo videos never show.
• Trusting the sandbox completely. Sandboxes skip fraud checks, use fake limits and return tidy data. Run a small live test before launch.
• Ignoring the price per call. An API that costs fractions of a cent per call can still eat your margin at 50 calls per user per day.
• Processing webhooks without signature checks. Anyone who finds the URL can send fake events.
• Hard-coding one AI or data vendor everywhere. Wrap each service in one module so a switch touches one file.

How can AI speed this up?

Give an AI assistant the vendor's OpenAPI spec and ask for a Postman collection that covers each endpoint with valid and invalid inputs. It can also turn a long error code page into a test case list in minutes.

The human check: AI invents fields and endpoints that don't exist, so compare every generated request with the current docs, and run it against the sandbox before trusting it. AI also can't read the vendor's terms of service for you with any authority; read the parts on rate limits, data use and termination yourself. To compare vendors before you test them, the F/MS startup tool comparisons and reviews save you some sign-ups.

Where does this SOP fit in your validation plan?

This SOP belongs to the Technical Validation SOPs:

1. Before it: prove the idea runs at all with a proof of concept, and place each service in the technical architecture review.
2. Alongside it: test how webhooks and stored API keys could be abused with the security validation SOP.
3. After it: check total response times under load with technical performance testing.

If you are new to building a product on other people's platforms, the F/MS free startup school covers the steps from idea to first customers.

FAQ

What is the difference between integration testing and unit testing?

Unit tests check one function of your own code in isolation, with outside services faked. Integration testing checks your code talking to real or realistically mocked outside services, including their errors and limits.

Can I test a third-party API without paying for it?

Yes, in most cases through a free sandbox or test mode: payment, email and data providers offer one. Budget a small live test anyway, since sandbox behaviour differs.

How do I test webhooks on my laptop?

Use a tunnel tool such as ngrok or the vendor's own CLI (the Stripe CLI forwards test events to localhost).

What success rate is good enough before launch?

This SOP uses 99% of test calls succeeding or failing safely, with zero silent failures. Silent failures matter more than the percentage, because customers find them before you do.