The ACORD 25 Certificate of Insurance API: A Technical Guide

If you have ever worked in commercial insurance, you know ACORD 25. It is the Certificate of Liability Insurance. It is the one your customer needs because the property manager will not give them keys, or the GC will not let them on site, or the city will not issue the permit. They need it today.

Some agencies issue a handful a week. High-volume books issue them every day. The form itself changes rarely (the edition in wide use dates from 2016), the data on it is sitting in your AMS, and yet certificates are often still issued one at a time, by hand.

This post walks through what it looks like to generate ACORD 25 certificates from a single API call. We will cover the fields, the common variants, additional insureds, and what to do about endorsements. For the product view without the code, see how to automate ACORD 25 insurance certificate creation with Mezdoc.

What is on the form

ACORD 25 is a one-page certificate that tells a third party (the "certificate holder") that a named insured has coverage in force. It is not a contract. It is informational only, which the form itself says in bold at the top. The third party reads it because they need proof that if your insured drops a forklift on their loading dock, somebody pays.

The fields fall into five blocks:

• Producer block (top left). Your agency name, address, contact name, phone, email.
• Insured block. The named insured and address.
• Insurers block (top right). The carriers providing each coverage, plus their NAIC number.
• Coverage rows. General Liability, Auto, Umbrella, Workers Comp, plus optional rows. Each row has policy number, effective date, expiration date, and limits.
• Certificate holder and description of operations (bottom). Often the most fragile box on the form, because it is free text that certificate holders and their COI tracking systems read closely.

Why teams still issue these by hand

A typical manual COI process looks like this:

• Customer or third party emails the request.
• Account manager looks up the policy in the AMS (Applied Epic, AMS360, HawkSoft, EZLynx, Nexsure).
• Account manager opens the AMS template editor, fills in certificate holder, description of operations, additional insured wording if needed.
• AMS generates the PDF. Account manager downloads it, attaches to email, sends.

It works. It is also a manual lookup and a round of retyping for every certificate, and when the third party comes back to ask for a different "additional insured" line, the whole round trip starts again.

When a certificate holder changes how its name should read, the same COI goes out again. Each re-issue is the same lookup and the same retyping.

How an automated COI flow works

Start with the ACORD 25 PDF your agency is licensed or authorized to use. Mezdoc does not supply ACORD forms: the form comes from your organization. Upload it once as a fillable PDF template and drop fields on the locations that correspond to the form blocks above. Each field gets an alias.

Publish v1 to production. Then every COI request becomes one HTTP call:

curl -X POST "https://api.mezdoc.com/api/v1/templates/acord_25_v1/render?async=true" \
  -H "Authorization: Bearer $MEZDOC_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "idempotency_key": "coi_2026_05_19_00481",
    "data": {
      "producer_name":     "Acme Insurance Services",
      "producer_address":  "1 Example Plaza, Suite 400, Tampa FL 33602",
      "producer_contact":  "Linda Park",
      "producer_phone":    "813-555-0142",
      "producer_email":    "linda@example.com",

      "insured_name":      "Bayside Logistics LLC",
      "insured_address":   "200 Example Way, Tampa FL 33605",

      "carrier_gl_name":   "Example Casualty Insurance Co",
      "carrier_gl_naic":   "00000",
      "gl_policy":         "GLP-2026-44102",
      "gl_effective":      "2026-04-01",
      "gl_expiration":     "2027-04-01",
      "gl_occurrence":     2000000,
      "gl_aggregate":      4000000,

      "cert_holder_name":  "Harbor Point Property LLC",
      "cert_holder_addr":  "200 Example Way, Tampa FL 33605",
      "description":       "Harbor Point Property LLC is named as Additional Insured per CG 20 10 04 13."
    }
  }'

The call returns 202 straight away with a submission id and a poll URL. When the PDF is ready, a signed submission.completed webhook tells your system, with a pdf_url it downloads using your API key. Your AMS or your CRM stores the submission id on the policy record. Send the same idempotency_key when you retry, and a dropped connection can never produce a second certificate.

Additional insureds and the description box

The Description of Operations / Locations / Vehicles box is a common source of re-issues, because certificate holders often request specific additional insured, contract-reference or waiver wording. The third party wants to be named as Additional Insured. They want the contract number on the certificate. They want a waiver of subrogation called out. They want the exact endorsement form number (CG 20 10, CG 20 37, etc).

Two patterns work well here:

Pattern A: structured description fields

Define separate fields for the common parts. additional_insured_name, endorsement_forms (an array), contract_reference, waiver_of_subrogation (boolean). Compose the description text from these fields with a calculated field (a formula over the other fields), instead of a free-form string.

Pros: every COI carries the same wording style. Re-issues are a one-field change.

Cons: account managers occasionally need to override the auto-generated text. So expose a raw description_override field that, if present, replaces the composed string.

Pattern B: raw description field

Keep one descriptionstring. Let the account manager type whatever the third party asked for. The flexibility helps. The downside is no consistency across certificates: one COI says "Additional Insured per CG 20 10 04 13", another says "AI per attached endorsement", which the third party's tracking system reads as different things.

Pattern B is faster to set up. Pattern A pays off once the same handful of wordings keeps coming back.

Handling endorsement schedules

Some certificate holders want a copy of the actual endorsement form attached to the COI. CG 20 10 04 13 is a one-page PDF. You can:

• Keep each endorsement form as a separate template in Mezdoc.
• Build a workflow that bundles the COI plus the endorsements the customer requested.
• Return a merged PDF: page 1 is the COI, pages 2 onward are the endorsements.

The customer gets a single packet. The third party stops emailing back to ask for the endorsement copy.

What it costs

The main cost is the engineering time to connect your AMS or policy system to the API, and that depends on how easily your AMS exports the data. After that, each certificate is one render against your plan's monthly allowance.

Three measures are worth tracking before and after, and here is where any change would come from:

• Time to issue a COI. The lookup and the retyping are replaced by one call from your system.
• Number of COI re-issues. The data comes from one source, and the description box is composed from structured fields rather than typed freehand.
• Time account managers spend on certificates. Each certificate becomes one call instead of a manual lookup.

One question that always comes up

Will the third party accept an API-generated COI? Acceptance requirements vary by certificate holder. Mezdoc fills the licensed ACORD form your agency provides; your team remains responsible for the wording, endorsements and recipient requirements. Each render is recorded as a submission with the template version and a SHA-256 of the PDF, and if someone signs through a Mezdoc link, the submission also records their IP address, device and time.

Start with the books that produce the most certificate volume. The big GCs, the master service agreements that require monthly proof, the city contracts. Wire those first. Everything else comes online once your account managers see the rhythm.

COIs rarely travel alone. To see how certificates fit next to quote letters, binders, and endorsements, read the insurance document automation overview.