MuleSoft runs the integration flow. Verirow checks the result.
A MuleSoft flow can finish successfully while individual records are still missing, duplicated, or different in the target system.
Your existing MuleSoft flow stays responsible for moving or transforming the data. Verirow only checks whether the final Source and Target data match.
Set up MuleSoft verification in five steps
Connect the system containing the original records before the MuleSoft flow moves or transforms them.
Connect the destination that should contain the completed flow result.
Select a stable identifier that represents the same record in both systems.
Choose the values that must be correct after the MuleSoft flow finishes.
Save the reconciliation so the same verification can run again after future flow runs.
Connect the systems MuleSoft is moving data between
Verirow does not need to become part of the data-moving logic. It only needs read access to the Source and Target records used for reconciliation.
The records before the MuleSoft flow transforms or moves them.
The records that should exist after the flow completes.
Use an endpoint that returns the records required for the verification.
Reconciliation generally requires read access, not write access.
Match the same business record on both sides
Verirow needs one identifier that exists in both Source and Target.
order_idinvoice_idcustomer_idexternal_idskuIf the MuleSoft flow maps or transforms the field name, the underlying business value still needs to represent the same logical record on both sides.
A changing status, timestamp, description, or generated value is usually not a safe record key.
Save the MuleSoft reconciliation once
Once Source, Target, matching key, and comparison fields are correct, save the configuration as a reusable check.
HubSpot Source + Salesforce Target + contact_id + email, lifecycle stage, owner.
That saved check becomes the verification definition you can run manually or trigger after a MuleSoft flow.
Run Verirow after the MuleSoft flow completes
The cleanest workflow is to trigger the saved Verirow check only after MuleSoft has finished writing the relevant target data.
Your normal MuleSoft flow finishes.
A final HTTP Request calls Verirow and starts the saved verification.
Verirow independently reads and reconciles both systems.
POST https://api.verirow.com/external-trigger/{SAVED_CHECK_ID}X-Verirow-Trigger-Token: {TRIGGER_TOKEN}Content-Type: application/json{
"provider": "mulesoft"
}Replace SAVED_CHECK_ID with the ID of the saved verification you want to run. Send the Trigger Token in the X-Verirow-Trigger-Token header. Keep the token in a MuleSoft secure property or secret and do not commit it to source control.
If the target connector or downstream system processes data asynchronously, trigger Verirow only after the final records are expected to be available.
What Verirow can reveal after MuleSoft
The Source and Target record match.
The expected record exists on one side but not the other.
The record exists, but one or more compared values differ.
The selected identifier appears more than once where it should be unique.
Common MuleSoft verification issues
MuleSoft succeeded but Verirow shows Missing
Check whether the destination record was committed before Verirow ran and confirm the same matching key exists on both sides.
Most records show Different
Review field mappings and transformations in the MuleSoft flow. Source and Target values may use different formats even when they represent similar business data.
Verirow runs too early
Trigger the verification only after the final action that writes or commits the target records has completed.
The same ID appears as Duplicate
Confirm the selected matching key is truly unique. If it is, the duplicate may represent a genuine data-quality problem.
The connection cannot load records
Recheck API URL, authentication, permissions, Records Path, and the response returned by the configured endpoint.
MuleSoft + Verirow questions
Does Verirow replace MuleSoft?
No. MuleSoft remains the integration platform. Verirow runs after the flow to independently verify the resulting data.
When should Verirow run?
Run Verirow after the MuleSoft flow has completed and the target system has finished receiving the records you want to verify.
What does Verirow verify after a MuleSoft flow?
Verirow compares source and target records using a shared record ID and the fields you choose to compare.
Can a MuleSoft flow succeed while the final data is still wrong?
Yes. A successful flow run confirms the workflow completed, but it does not by itself prove that every record arrived in the target with the expected values.
Do I need to rebuild my MuleSoft flow?
No. You can keep your existing flow and add Verirow as a separate verification step after the flow completes.
What should I use as the record ID?
Use a stable identifier that exists in both systems, such as order_id, customer_id, invoice_id, external_id, or another business key.