When an integration breaks, the first question is often simple: did the API call succeed?
That is a useful question, but it is not the whole question. A successful API request usually means one system received a request and returned an acceptable response. A successful data sync means the right information landed in the right place, matched the right record, passed validation, avoided duplication, and can be trusted later in reporting or operations.
Those are different outcomes. Treating them as the same thing is how organizations end up with “successful” integrations that quietly create duplicate contacts, skip rejected records, miss donation updates, overwrite good CRM fields, or leave dashboards with numbers nobody can explain.
This article explains the difference and gives teams a practical way to evaluate whether an integration is actually working, not merely returning polite API responses.
The request is only one step in the workflow
An API request is a message sent from one system to another. It may create a record, update a field, retrieve data, trigger a workflow, or acknowledge an event. If the receiving system returns a success response, the sending system knows the request was accepted at that moment.
But a data sync usually includes more than a single request. A complete sync may need to:
- Receive a webhook or scheduled export
- Verify that the request is authentic
- Parse the payload into expected fields
- Normalize names, dates, amounts, statuses, and identifiers
- Match the incoming record to an existing person, account, order, gift, ticket, or submission
- Decide whether to create, update, skip, or reject the record
- Write the change to the destination system
- Store a log entry that explains what happened
- Retry temporary failures without duplicating permanent successes
- Reconcile totals against the source system later
The API response may only describe one part of that chain. A 200-level response can be technically true while the larger business workflow is incomplete.
A fictional example: the donation update that “worked”
Imagine a nonprofit donation platform sends a webhook when someone completes an online gift. The receiving integration posts the donor and gift data into a CRM. The webhook endpoint returns a success response, so the donation platform marks the delivery as complete.
Later, the fundraising team notices the campaign dashboard is missing several gifts. The integration logs show successful requests, but the CRM rejected some records because a required campaign code did not match an active CRM campaign. Other records created duplicate constituents because the incoming email address was different from the one already stored in the CRM.
From the webhook sender’s point of view, the delivery worked. From the organization’s point of view, the sync did not.
The failure happened after receipt. The integration accepted the message, but it did not prove that each record was saved, matched, classified, and counted correctly.
What the status code can and cannot tell you
Status codes are important. They help systems determine whether a request was received, whether authentication failed, whether the server had an error, or whether the request was malformed. For example, Salesforce documents REST API error responses so clients can understand whether a request failed because of authorization, invalid data, service availability, or other conditions. That level of feedback matters for troubleshooting.
Webhook platforms also have delivery rules. Stripe documents webhook delivery and retry behavior, including automatic retry handling for undelivered events. GitHub’s webhook documentation explains that a server should respond quickly with a 2xx response and that failed deliveries can be inspected and redelivered, although GitHub does not automatically redeliver every failed webhook. Those platform-specific details shape how an integration should be designed.
But status codes are not a replacement for business validation. They usually cannot answer questions like:
- Did this incoming person match the correct existing CRM record?
- Was the submitted amount stored in the correct currency and field?
- Did the destination system accept every record in a batch?
- Was a duplicate prevented or accidentally created?
- Did a later workflow overwrite the value?
- Did the reporting table receive the same record the CRM received?
Those questions require sync-level validation, not just request-level logging.
The integration should separate accepted, rejected, skipped, and retried records
A reliable sync should not treat every non-error as success. It should classify outcomes in a way that humans can review.
Accepted means the record passed validation and was written to the destination system.
Rejected means the record could not be processed because something was wrong with the data or the business rule. Examples include a missing required ID, an invalid date, an unknown campaign code, or a value that does not fit the destination field.
Skipped means the integration intentionally did not process the record. Maybe the event was not relevant, the record was already processed, or the update was older than the destination data.
Retried means the integration attempted the operation again after a temporary problem, such as a timeout, rate limit, or unavailable service.
These categories help teams see the real health of the workflow. “10,000 requests received” is less useful than “9,720 accepted, 180 skipped as duplicates, 85 rejected for missing IDs, and 15 pending retry.”
Idempotency protects you from duplicate work
Many integration problems come from retries. A webhook sender may deliver the same event more than once. A scheduled job may rerun after a timeout. A human may manually replay a file. Without a duplicate-safe design, a retry can create a second gift, a second ticket, a second invoice, or a second email subscription.
Idempotency is the design principle that allows the same operation to run more than once without creating a different result after the first successful processing. In practical terms, the integration needs a stable event ID, source record ID, transaction ID, or idempotency key that lets it recognize work it has already completed.
For business teams, the plain-language version is this: the integration should know the difference between “I have never seen this record” and “I already processed this exact event.”
Validation should happen before the destination system becomes the test
Some integrations rely on the destination platform to reject bad data. That may catch certain errors, but it often produces vague failures and messy recovery work. A better design validates expected conditions before making the final write.
Useful validation checks include:
- Required identifiers are present
- Dates use an expected format and timezone assumption
- Amounts are numeric and mapped to the correct currency field
- Picklist values match destination options
- Email addresses and phone numbers are normalized consistently
- Source campaign, form, survey, or product codes exist in the destination system
- Updates are newer than the destination record when freshness matters
When validation fails, the record should move into a reviewable rejected-record queue or log. It should not disappear, and it should not be counted as synced.
Batch syncs need record-level reporting
Batch imports can be especially misleading. A nightly sync may report that a file was delivered or an import request completed, while individual rows failed inside the batch. If the only monitoring happens at the file level, teams may not notice missing records until a staff member spots a reporting gap days later.
Record-level reporting should show how many records were read, created, updated, rejected, skipped, and retried. It should also preserve enough context to investigate failures without exposing unnecessary sensitive data. For example, a log might store a source record ID, destination record ID, operation type, timestamp, error category, and short reason. It usually should not store full sensitive payloads forever.
Reconciliation proves the sync stayed true over time
Even a well-designed integration can drift. A platform changes a field option. A new form uses a different source code. A CRM admin adds a required field. A marketing platform changes how it formats consent values. A webhook endpoint is available, but a downstream reporting table is not.
That is why integrations need reconciliation checks. Reconciliation compares the source and destination after the sync runs. The goal is to answer practical questions:
- Do source and destination record counts match for the expected period?
- Do totals, such as donation amount or order value, match within an acceptable tolerance?
- Are rejected records being reviewed and resolved?
- Are retry queues draining or growing?
- Are key fields complete in the destination system?
- Can a sample of records be traced from source to destination and into reporting?
Reconciliation is not glamorous, but it is where trust is earned. It turns integration monitoring from “the job ran” into “the data is still reliable.”
A practical acceptance test for data syncs
Before launching or trusting an integration, test the workflow with known examples. Include normal records, edge cases, duplicate events, invalid values, missing IDs, and temporary failure scenarios.
A useful acceptance test should confirm:
- The source system sends the expected event, file, or API payload
- The integration verifies authentication or signature requirements where applicable
- Stable identifiers are used for matching, not only names or email addresses
- Valid records create or update the correct destination records
- Invalid records are rejected with a clear reason
- Duplicate events do not create duplicate destination records
- Temporary failures trigger retry behavior
- Permanent failures stop retrying and become reviewable
- Logs are understandable to the people responsible for support
- Reconciliation checks confirm totals and sample records after processing
The test should involve both technical and operational stakeholders. Developers can confirm API behavior, but business users often know whether a record landed in the right campaign, segment, household, project, or report.
The real measure of integration success
A successful API request is a good signal. It means two systems communicated. But a successful data sync is a stronger outcome. It means the communication produced trustworthy operational data.
For DigitalWerks, the important question is not only whether an integration can be connected. It is whether the workflow can be monitored, explained, repaired, and trusted when people depend on it for decisions.
If your team is relying on connected systems but still finding missing records, duplicate contacts, unclear reports, or manual spreadsheet cleanup, DigitalWerks can review the full data path and help design a sync process with validation, logging, retry handling, and reconciliation built in.