Integration Audit

Who the integration audit is for

You have an integration that moves money, bookings or customer records, and you did not build it. The agency has moved on, the developer left, or it was set up years ago and nobody is sure how it works. It runs, mostly: an invoice is occasionally doubled, a booking goes missing, someone re-authorises a connection without knowing why. You want to know whether to trust it, from evidence rather than reassurance.

The audit assesses the integration as it is, in your systems, and reports what would fail, how badly, and what it takes to fix. It works on a connector built on Zapier, Make or n8n, a coded integration between a website and Xero, HubSpot or ServiceM8, or a multi-system sync, with the depth adjusted to what is there.

What the audit tests

The method is the one we use for the Standard SEO & AI Readiness Audit: fixed checks, recorded evidence, severity ratings and a score. Every check is the one we run on integrations we build ourselves.

• Contracts: tests written against each vendor API and run, recording where the vendor's current behaviour no longer matches what the code assumes.
• Workflows: real records pushed through each workflow end to end, in a sandbox or with safe records, comparing what arrives with what should have. Field mismatches, silently dropped records and lossy transformations are captured here.
• Limits: the integration's behaviour at each vendor's published call limits. Queue and back off, or drop records.
• Failure modes: a token that expires mid-run, a webhook delivered twice after a timeout, a batch that fails halfway, the same event arriving twice. An integration that creates two invoices from one event fails.
• Security: where credentials live and how they are used. Tokens in client-side code or a spreadsheet are findings of the highest severity. Every exposed endpoint is tested for insecure direct object references, and credential rotation is checked for whether it is possible without a code change.
• Monitoring: whether health checks exist, whether alerts reach a person, and whether a failed run can be identified and replayed. If a customer would be the first to notice an outage, that is a finding.

How findings are scored

Each finding carries the failure it would cause, the evidence that it exists, a severity, an effort estimate and an owner. Findings roll up into a score across contracts, workflows, limits, failure modes, security and monitoring, weighted so a credential in a browser bundle outweighs a missing alert. Page one is for whoever is accountable for the systems; the following pages are for whoever will do the work. Where the right fix is a rebuild rather than a patch, the report says so and names the tier, whether a standard integration build or a two-way sync and multi-system integration.

What we need from you

Access to the platform accounts on each side of the integration, granted as read access to an account we name, and a description of what the integration is supposed to do in plain terms. Code access helps but is not required: contract, workflow, limit and failure-mode tests run from the outside against the vendor APIs and the workflow itself. With code we can confirm credential handling and object-reference findings directly rather than inferring them. Where a vendor sandbox is needed and the vendor charges for it, that is named in the quote and settled before we begin.

After the audit

The audit is a complete deliverable, so its fee is not credited against later work; that is the opposite of integration discovery and scoping, which is partial work toward a build. Fixes can be quoted from the report without a separate scoping engagement, and the integration support retainer picks up from the audit if you want the integration kept healthy rather than repaired once. You own the report, the test suites written to produce it, and the accounts we were given access to. Third-party fees the audit incurs, such as a vendor sandbox that is charged for, are named in the quote.