The most common causes of silent integration errors

Silent integration errors corrupt data without raising an alarm. Learn the three most common causes and how to prevent them in FileMaker integrations.

Your integration runs, your connector reports success, and your dashboard shows green. But three weeks later a customer is invoiced twice, a shipment goes to the wrong address, or a batch of orders simply vanishes from the sync. Nobody triggered an alert. No error log flagged it. The problem was there from day one — silent, accumulating, invisible.

This article explains exactly why that happens, focuses on the three most common root causes, and gives you the concrete steps to find and fix them before they become expensive.

What makes an integration error "silent"?

A silent integration error is one where the technical layer — the API call, the connector script, the sync job — completes without throwing an exception, but the business data ends up wrong. The system believes it succeeded. Only a human reviewing the actual records weeks later discovers the damage.

Silent errors are fundamentally different from loud errors (a 500 HTTP response, a timeout, a FileMaker script that halts on error). Loud errors are annoying but safe — they stop processing and force someone to act. Silent errors are dangerous precisely because they don't stop anything. They let bad data propagate quietly through every downstream system that depends on the integration.

The three causes below account for the vast majority of silent errors we encounter in real FileMaker ↔ Exact Online and FileMaker ↔ REST API integrations.

Cause 1: Incorrect field mapping

What actually goes wrong

Field mapping is the step where you tell the integration: "take the value from field X in system A and write it to field Y in system B." When the mapping is wrong — or becomes wrong after a system update — data flows perfectly but lands in the wrong place.

Here is a concrete example. A company connects FileMaker to Exact Online to sync customer invoices. The FileMaker field Payment_Terms_Code contains a numeric code (e.g. 30 for net-30). Exact Online expects a reference ID for its payment condition object, not the raw number. The integration was built quickly, the field was mapped directly, and it worked during testing because the test customer happened to have a payment condition whose internal ID was also 30. In production, most customers have IDs in the 400–600 range. Every invoice syncs without error. Every invoice silently gets the wrong payment terms — or no terms at all if Exact Online quietly ignores an unresolvable reference.

Why it stays silent

REST APIs and Exact Online's API typically return a 200 OK even when a field value is ignored or coerced. They validate structure (is the JSON well-formed?) not always business semantics (does this payment condition ID actually exist?).
FileMaker's Insert from URL or Data API scripts report success based on HTTP status, not on whether the receiving system stored the value correctly.
No one is checking the Exact Online records against the FileMaker source after the sync.

How to catch and prevent it

Map against API documentation, not assumptions. For Exact Online, always check the division-specific reference tables (payment conditions, GL accounts, cost centres) and map to their internal IDs, not human-readable codes.
Build a post-sync verification step. After writing a record, immediately read it back from the target API and compare at least the critical fields. If the round-trip values don't match, log it as a warning — even if the write returned 200.
Use a staging/validation layer. Before sending data, resolve all reference fields (payment condition codes → Exact Online IDs) through a lookup table maintained in FileMaker. Refresh that lookup table on a schedule so it stays current after Exact Online configuration changes.
Run a periodic reconciliation job. Once a week, pull a sample of recently synced records from both systems and diff the critical fields. Five minutes of scripting here has caught mapping drift that went unnoticed for months.

Cause 2: Records silently skipped by filters

What actually goes wrong

Every integration has filters — conditions that decide which records qualify for sync. The logic seems obvious at build time. It quietly breaks when the business changes its data.

A real scenario: a FileMaker-based order management system syncs sales orders to Exact Online only when the order status is Confirmed. For two years this works perfectly. Then the sales team starts using a new status value, Approved, introduced by a consultant who customised a FileMaker layout. Approved orders never reach Exact Online. No error fires. The integration simply skips them. Finance notices the revenue discrepancy weeks later during a month-end close — not because of a system alert but because a human compared two spreadsheets.

A REST API version of the same problem: an integration queries an external REST API using a date-range filter to fetch new records since the last sync. The filter uses created_at >= last_run_timestamp. If the API's server clock is even 2–3 seconds ahead of the integration host, records created in that gap are permanently skipped. No retry, no error, no log entry.

Why it stays silent

Filters that return zero results look identical to filters that legitimately find nothing to sync. Both are "success."
FileMaker's Find requests don't raise an error when they return no records — they return a zero-count result set. The sync loop simply exits immediately.
A REST API returning an empty array [] is a valid, successful response. The connector has no way to know whether zero results is correct or a missed batch.

How to catch and prevent it

Make zero-result runs visible. Log every sync run with its result count. Alert (email, Slack, or a dashboard flag) when a sync that normally processes 50+ records suddenly returns zero. "Nothing to sync" is worth investigating.
Audit filter conditions regularly. When a new status value, category, or flag is introduced in FileMaker, check every integration that filters on those fields. Treat it as a required step in your change management process, not an afterthought.
Add a timestamp buffer to REST API date filters. Instead of created_at >= last_run_timestamp, use created_at >= last_run_timestamp - 5 minutes. Handle the resulting duplicates with idempotency (see Cause 3). It is always safer to process a record twice than to miss it once.
Build a "missing records" report. Once a month, run a query that counts records in FileMaker that should have been synced versus records that actually appear in Exact Online. A persistent gap is a filter problem.

Cause 3: Duplicate records from missing idempotency

What actually goes wrong

Idempotency means: if you process the same record twice, the end result is identical to processing it once. Without it, retries and overlapping sync windows create duplicates — often in the system that is hardest to deduplicate, like Exact Online's ledger.

A concrete example: a FileMaker script sends a sales invoice to Exact Online via the REST API. The API call succeeds, Exact Online creates the invoice, but the HTTP response times out before FileMaker receives it. FileMaker's Insert from URL returns an error. The script marks the invoice as "not yet synced" and retries on the next run. Exact Online now has two identical invoices. The customer receives two payment requests. The revenue is double-counted.

Another scenario: two FileMaker clients have the integration running simultaneously (perhaps a scheduled server script and a user-triggered script). Both find the same unsynced order within the same 30-second window. Both send it. Two duplicate purchase orders appear in Exact Online.

Why it stays silent

Both API calls return 201 Created. Both are technically correct. The integration has no way to know a duplicate was just created.
FileMaker doesn't natively lock a record during an async API call, so concurrent execution is a real risk on FileMaker Server-hosted solutions.
Exact Online does not always reject duplicates — it will happily create two invoices with the same reference number unless you enforce uniqueness on your side.

How to catch and prevent it

Assign and store an external reference ID before the API call. Before sending anything to Exact Online, write a unique external reference (e.g. FM-INV-00412) into your FileMaker record and include it in the API payload as the YourRef or equivalent field. On retry, search Exact Online for that reference before creating a new record — update if found, create only if not found.
Use a sync-lock flag in FileMaker. Set a Sync_In_Progress field to 1 at the start of the sync process and back to 0 on completion (success or failure). Script triggers or a found-set filter should skip records where this flag is already 1. This prevents concurrent execution from processing the same record twice.
Implement a "check-then-act" pattern for every write operation. The pattern: (a) query the target system for the external reference, (b) if found, PATCH/update; if not found, POST/create. Never POST blindly on retry.
Log the target system's response ID immediately. When Exact Online returns a new record ID, write it back to FileMaker in the same script step that processes the response. If that write fails, you have a narrow window of risk — handle it with a cleanup job that cross-references unmatched IDs.

Silent error detection checklist

Use this before you go live with any new integration, and revisit it quarterly:

Every sync run logs its start time, end time, record count, and any warnings
Zero-result sync runs trigger a notification if the historical average is above zero
All filter conditions are documented and reviewed whenever source data structures change
Every write to a target API includes a unique external reference in the payload
A post-write verification reads back at least the critical fields from the target
Sync-lock flags or equivalent concurrency controls are in place
A monthly reconciliation report compares source and target record counts for key entities
API response IDs from the target system are stored back in the source record immediately
Date-range filters include a safe overlap buffer to avoid clock-skew gaps
Field mapping is validated against the live API reference documentation, not a cached copy

How to run a silent error audit on an existing integration

If you have an integration already running in production and you suspect it may have silent errors, here is a practical approach:

Pull a full export from both sides. Export the relevant entity (invoices, orders, contacts) from FileMaker and from Exact Online for a defined date range — say, the last 90 days.
Match on your external reference field. If you have one, this is straightforward. If you don't, match on a combination of date + amount + customer reference — imperfect but enough to find obvious gaps.
Flag three categories: records in FileMaker but not in Exact Online (skipped), records in Exact Online but not in FileMaker (duplicates or externally created), and records present in both but with differing values (mapping errors).
Quantify before you fix. Count the discrepancies. A handful over 90 days is a low-priority polish task. Hundreds suggest a structural flaw that needs immediate attention before it damages financial reporting.
Fix the root cause, not just the symptom. Correcting the 47 duplicates in Exact Online manually is necessary but insufficient. Find which of the three causes above produced them and apply the corresponding prevention measure.

Frequently asked questions

Can Exact Online's API tell me if a field value was silently ignored? Not reliably. The Exact Online REST API returns a 200 or 201 with the created/updated resource in the response body. The safest approach is to read back the specific fields you care about from that response body and compare them to what you sent — do not assume that a 200 means every field was stored as intended.

How do I handle the check-then-act pattern without slowing down bulk syncs? Batch your external-reference lookups. Instead of one GET per record, query Exact Online for a list of existing references in a date range at the start of each sync run and build a local lookup table in FileMaker. Then compare locally before deciding whether to POST or PATCH. This reduces API calls from N per record to 1 per sync batch.

What if I inherited an integration that has no external reference field? Add one now, before the next sync runs. You cannot retroactively guarantee idempotency for past records, but you can prevent future duplicates from the moment you add the field. For the historical data, run the manual audit described above and resolve the backlog once.

Is a silent error always caused by the integration, or could the source data be wrong? Both happen. A common source-data issue in FileMaker is a record that passes the sync filter but contains a null or malformed value in a required API field. Exact Online silently stores a default or ignores the field. Build validation at the source: before any record is queued for sync, verify that required fields are populated and within the expected format. Reject at the source with a visible error rather than let the API handle (or mishandle) it silently.

How often should I run reconciliation reports? For financial integrations (invoices, purchase orders, payments), weekly is the minimum. For CRM or product catalogue syncs, monthly is usually sufficient. The higher the cost of a discrepancy discovered late — financial, regulatory, or reputational — the more frequently you should reconcile.

Dealing with silent integration errors is ultimately a design discipline, not a debugging task. The systems that stay clean over years are the ones where logging, reconciliation, idempotency, and filter auditing were built in from the start — not bolted on after the first incident. If you are building or overhauling an integration between FileMaker and Exact Online, connecting FileMaker to external REST APIs, or trying to make sense of data discrepancies in a system already in production, Loggix works on exactly these problems: designing integration architectures that fail loudly when something goes wrong, and stay reliably quiet when everything is right.