Automating ACORD 25 Verification for Vendor Onboarding

What a certificate of insurance actually is

The ACORD 25 is the standard industry form insurance agents use to show that a policy exists — general liability, auto, umbrella/excess, workers' compensation, and so on — along with the limits, effective and expiration dates, and whether the party requesting the certificate has been added as an additional insured or granted a waiver of subrogation. It's issued as a matter of information only: the certificate itself doesn't amend, extend, or alter the coverage of the underlying policy, which is exactly why checking it carefully against your own actual requirements matters — the form can look complete while still missing something the contract requires.

Why manual review is slow and easy to get wrong

Checking a certificate by hand against a contract's requirements — minimum liability limits, additional-insured status, waiver of subrogation, valid policy dates — is slow, repetitive work, and it's easy to miss something in a dense, differently-formatted PDF from a different insurance agent every time. A missed additional-insured endorsement or an expired policy is exactly the kind of gap that turns into an uninsured loss the general contractor, landlord, or franchisor ends up covering instead of the vendor.

This isn't a one-time check either. Certificates expire and need to be re-verified at renewal, and a vendor-management process that only checks at initial onboarding will eventually be relying on a lapsed certificate without knowing it. Worth saying plainly, since this guide raises the problem: Aervik Labs sells the check, not the calendar. Our API verifies a certificate when you send it one. Tracking which vendor is due for re-verification stays in your system, where the vendor relationship already lives.

What a real automated check needs to do

• Extract every standard coverage section from the certificate — not just the headline liability limit.
• Compare the extracted data against your own actual requirements (which vary by contract or property), not a generic checklist.
• Return an itemized list of exactly what's missing or deficient, not just a pass/fail flag.
• Tell you, field by field, when it could not read a value — as a different answer from “not on the certificate”. Scanned, faxed, and photographed certificates are never perfectly readable, and a confidence score attached to a value the tool filled in anyway is not the same as the tool declining to fill it in (why).
• Say which of your rules it actually evaluated, so a rule it skipped can’t read as a pass.
• Reach the verdict by fixed rules over the extracted values, so the same certificate and the same requirements always give the same answer.

How Aervik Labs' COI / ACORD 25 Compliance Verification API handles this

This API takes a certificate as an image URL or a base64-encoded image or PDF and extracts everything on it — named insured, insurers, each coverage section's limits and dates, additional-insured and subrogation-waived flags — with a confidence score on the extraction. Send your own coverage requirements in the same call and it also returns a verdict — compliant, deficient, or cannot_determine when a field a rule depends on could not be read — with an itemized list of exactly what's missing. The verdict itself is a fixed, deterministic rules engine over the extracted fields, not an AI guess, so the same requirements and the same certificate always produce the same answer.

Two ways to send your rules: inline on every /verify call, or save a named requirement set once with POST /requirements and reference it by id afterwards. Both are backed by a real database, so an id you receive stays resolvable. The product page has the detail.

Or try it on a real certificate right now, free and without signing up: the COI checker runs the same code this API does, including the part that tells you which fields it could not read.

Wiring it into n8n, Make or another workflow tool

No connector is needed: any tool with an HTTP request step can call the API — n8n's HTTP Request node or Make's HTTP module, for example. The parts that decide whether the workflow is safe to leave running:

• Send email attachments as base64. A PDF goes as base64_image with "mime_type": "application/pdf". A URL ending in .pdf is refused with 400 pdf_url_unsupported; file_url is for images.
• Keep the key in the tool's credential store as the X-RapidAPI-Key header, not typed into the workflow, so a shared or exported workflow carries no key.
• Keep limits out of the workflow. Send your requirements as data, or save them once and pass the id (the requirements schema), so changing a contract minimum does not mean editing every branch.

Route on fields, never on text a model wrote:

The last two rows are what keep a workflow from quietly approving certificates nobody checked. The product page shows a real cannot_determine response.

What to send when a certificate fails

Every deficiency carries a reason written to be read by a person, and a status that says who can fix it. Group the list by status before writing to anyone, so one message does not ask a vendor for coverage they may already have:

See the full COI / ACORD 25 Compliance Verification API

Further reading: why manual certificate-of-insurance review misses things , and how it fits with Aervik Labs' compliance and vendor-risk products.