How to test integrations

You've connected FileMaker to your webshop, your accounting package, or an AI service, and everything works — until the day it doesn't. An order silently fails to sync to Exact Online, an API key expires and nobody notices for three weeks, or a script that has run flawlessly for two years suddenly chokes on a name field containing an emoji. This article walks through how to actually test integrations so these failures get caught in a test environment, not in front of a customer.

Why do integrations break more often than "normal" software?

A standalone FileMaker solution only has to behave correctly within its own four walls. An integration depends on at least one other system staying stable, reachable, and consistent — and you don't control that system.

Concrete example: a Loggix client had a working connector between FileMaker and a shipping carrier's API. The carrier pushed a minor API update that changed a date format from YYYY-MM-DD to an ISO timestamp with timezone offset. Nothing in FileMaker changed. Nothing in the client's process changed. But every new shipment label request started failing overnight, because the script parsing that date field assumed the old format.

This is the core truth about integration testing: you're not just testing your own code, you're testing the seam between two systems that can each change independently. That seam is where almost every integration bug lives.

What actually needs to be tested in an integration?

Most teams only test the "happy path" — does the data go from A to B when everything is normal? That's necessary but nowhere near sufficient. A proper test plan covers:

1. The happy path — a normal order, a normal customer record, a normal AI prompt, flows through correctly end to end.
2. Malformed or unexpected input — empty fields, special characters, unusually long text, wrong data types (a phone number typed into a numeric field).
3. Partial failure — the connection drops halfway through a batch of 500 records. What happens to record 251?
4. Authentication and token expiry — API keys, OAuth tokens, or certificates that expire or get revoked.
5. Rate limits and throttling — what happens when you send 2,000 requests to a service that only allows 100 per minute?
6. Duplicate and out-of-order delivery — the same webhook fires twice, or a "created" event arrives after the "updated" event for the same record.
7. Downstream system downtime — the other system is simply offline or returns a 500 error.
8. Data mapping edge cases — a Dutch address field with a house number extension, a name with an apostrophe, a decimal comma versus a decimal point.

If your test plan only covers point 1, you have a demo, not a tested integration.

How do you set up a safe environment to test in?

You never want to test against your live accounting system, live webshop, or a production AI account that's billed per token. Set up a proper separation:

• Sandbox or test accounts — most serious platforms (Exact Online, e-Boekhouden, Shopify, Stripe, OpenAI-style AI APIs) offer a sandbox or test-mode environment. Use it, even if it takes an extra hour to set up.
• A cloned copy of your FileMaker file — with a separate data source pointing to the sandbox, never the live API endpoint. This should be routine practice, and it's exactly the kind of environment discipline covered in Loggix's guide on how to make custom business software reliable and transferable.
• Realistic but fake test data — not three neat sample records, but a data set that mirrors the messiness of your real data: long names, missing fields, old records, special characters.
• A way to reset state — you need to be able to run the same test twice. If test 1 leaves the sandbox account in a modified state, test 2 isn't clean anymore.

What does a step-by-step integration test actually look like?

Here's a workflow that works well for a FileMaker-to-external-system integration, whether that's an ERP connector, a webshop sync, or an AI tool like Klai processing text inside FileMaker:

1. Write down the contract first. Before testing anything, document exactly what fields go in, what format they're expected in, and what comes back. If nobody can state this in one sentence per field, that's your first bug.
2. Test authentication in isolation. Can you get a valid token/response with a bare-bones test call (Postman, curl, or a simple FileMaker script with Insert from URL) before any business logic runs?
3. Send one clean record through manually and verify it end to end — not just "the script ran without error," but open the target system and confirm the data landed correctly, in the right field, with the right formatting.
4. Feed it deliberately bad data. An order with no email address. A product with a price of 0. A customer name that's 300 characters long. Watch what happens — does it fail loudly (good) or silently (bad)?
5. Simulate a dropped connection. Turn off wifi mid-sync, or point the call at a URL that times out. Does the script hang forever, or does it fail gracefully and log the error?
6. Run a batch, not just one record. Ten records is different from one. A thousand is different from ten. Batch testing surfaces rate limits, memory issues, and performance walls that single-record testing never will.
7. Re-run the exact same batch a second time. This is how you catch duplicate-creation bugs — does re-sending the same order create a second copy downstream?
8. Check the logs, not just the outcome. If something goes wrong three weeks from now, will you be able to tell which record failed and why? If the integration doesn't log its own errors, that's a gap to close before go-live, not after.
9. Test the failure notification path. If a sync fails, does anyone actually find out? A script that fails silently at 2am on a Sunday is worse than no integration at all, because everyone assumes it's working.

How is testing an AI integration different?

AI tools embedded in FileMaker — for example using a service like Klai to summarize records, classify support tickets, or draft customer replies — introduce a new category of test case: non-deterministic output. The same input can produce a slightly different answer each time.

For AI integrations, add these tests to the list above:

• Run the same prompt 10 times and check whether the variation in output is acceptable for your use case, or whether you need stricter prompt constraints or output validation.
• Test with an empty or near-empty input. What does the AI do with a support ticket that just says "help"?
• Test for hallucinated fields. If the AI is asked to extract a customer number from free text and none exists, does it invent one, or correctly return "not found"?
• Set and test a timeout and fallback. AI API calls can be slower and less predictable than a typical REST call to your ERP. Your script needs a sane timeout and a defined fallback behavior, not an indefinite wait.
• Budget-test it. Run a realistic daily volume through the sandbox and check the token cost, so a runaway loop doesn't produce a surprise invoice.

How does testing an embedded form or UI layer fit in?

Integrations aren't only server-to-server. A tool like FmBetterforms, used to render modern web-style forms inside FileMaker, is also an integration point — between your FileMaker layout logic and a JavaScript/web rendering layer. The same discipline applies:

• Test the form with a browser's developer tools open to catch silent JavaScript errors that FileMaker itself won't report.
• Test on the actual devices and browsers your users have (a form that renders perfectly in FileMaker Pro on a Mac can behave differently in WebDirect on a tablet).
• Test what happens when a user submits the form twice quickly, or hits back mid-submission.
• Test with a slow network connection, not just your fast office wifi — this is often where these UI integrations quietly fail in the field.

What should an integration test checklist include before go-live?

Use this as a final gate before any integration goes live:

• Happy path tested end to end with real-looking data
• Bad/malformed input tested and fails safely, with a clear error message
• Batch volume tested at realistic and peak volume
• Duplicate delivery/re-run tested
• Authentication expiry tested (what happens the day the token dies?)
• Downstream downtime simulated
• Errors are logged somewhere a human will actually see them
• Someone is notified automatically when a sync fails
• Rollback or reconciliation process exists for when things do go wrong
• Documentation exists so a developer who didn't build it can debug it

FAQ

How much time should we budget for integration testing? As a rule of thumb, plan for testing to take as long as building the integration itself. Integrations that feel "quick to build" are usually the ones where testing gets skipped, and they're disproportionately the ones that fail in production.

Can we skip a sandbox environment if the API doesn't offer one? No — if the vendor has no sandbox, build your own safety net: a duplicate account, a restricted test dataset, or a manual approval step before any test data reaches real customers or real invoices.

Who should own integration testing — the developer or the business user? Both. The developer verifies the technical contract works; the business user verifies the result actually makes sense in context (the right customer, the right amount, the right status). A test that only checks "no error was thrown" misses business-logic bugs.

What's the single most common integration bug you see in practice? Silent partial failure — the integration reports success, but only handled part of the batch, or handled it with slightly wrong data. Loud, obvious failures get fixed fast. Quiet, half-correct ones do damage for months before anyone notices.

A well-tested integration isn't a one-time project milestone — it's part of keeping a custom system reliable and maintainable for the years ahead, which is exactly why testing discipline belongs in the same conversation as documentation and transferability. If you're building or auditing a FileMaker integration, an ERP connector, an AI workflow, or a custom API bridge and want a second set of eyes on the test plan before it goes live, Loggix can help map out the right approach — from a targeted technical review to hands-on development of the connector itself.