policy packets for US MGAs, wholesale brokers and program administrators
Build the right insurance policy packet from one set of policy data.
Declarations, coverage forms, state notices, endorsements and a schedule of forms. Change the risk, and the packet follows the rules your team configured.
Try another risk
Florida risk, additional insured, waiver of subrogation: 6 documents.
Added by a rule your team configured
Why did that page change?
- Florida risk?Add the Florida notice.
- Additional insured?Add the endorsement.
Your team defines the document rules. Mezdoc applies them consistently.
Under the hood, a rule is a short condition on the policy data:
state == "FL"additional_insured == truestate == "TX" && surplus_lines == true
Loose documents in. One policy packet out.
- One merged PDF
- Separate PDFs
- Both
One merged PDF
Every included document, in order, as one file.
Separate PDFs
Each document as its own file, named by its alias.
Both
The merged packet and the separate files, or a zip of everything.
Unless the workflow turns it off, each run also produces a certificate of completion as its own PDF, with the workflow version, the document count and a SHA-256 of the delivered documents.
New form edition? Old packets stay as they were.
- Developmentv5 mapped
- Stagingv5 tested
- Production
The schedule of forms is a dynamic document.
It lists the forms with a FOR EACH over a list your system sends, or with IF blocks that read the same fields as your include rules. Your own form numbers, editions and titles come from the data.
Mezdoc does not compile the schedule from the packet on its own. It renders what the schedule template says, so your team keeps the schedule and the include rules in step.
for your engineers
Your system sends the policy. Mezdoc sends the packet back.
Keep policy records, rating and issuance decisions where they are. Your integration posts the policy data from your PAS, AMS or rater to the workflow run API, and stores the packet that comes back.
- 01POST the policy data, keyed by the workflow's field aliases.
- 02Mezdoc applies the include rules and renders every included document.
- 03The merged packet and each document come back, or a signed webhook says they are ready.
Earlier in the lifecycle, the same approach produces the quote letter and the binder: see the quote-to-binder document workflow.
curl -X POST https://api.mezdoc.com/api/v1/workflows/policy_packet/runs \
-H "Authorization: Bearer $MEZDOC_API_KEY" \
-H "Content-Type: application/json" \
-d '{ "data": { "insured_name": "Harbor Point LLC",
"state": "FL", "product": "GL",
"additional_insured": true,
"waiver_of_subrogation": true } }'{
"run_id": "run_4Tz9Lq2Wm",
"status": "completed",
"merged_pdf_url": ".../runs/run_4Tz9Lq2Wm/pdf?doc=merged",
"documents": [ "declarations", "florida_notice", ... ]
}Conditional insurance forms, state notices and endorsements.
Mezdoc workflows include each configured document only when its rule is true for the submitted policy data. Rules compare fields with ==, !=, >, <, contains or startsWith, and join conditions with && and ||. Name a condition once, such as coastal_fl, and reuse it on several documents.
Endorsement selection works the same way: the endorsement is a document, and the coverage selection in your data is its rule. Mezdoc reads the value your system sends; it never infers an endorsement from the risk. ACORD forms join a packet the same way: see how to automate ACORD 25 insurance certificate creation.
| Include rule | Document it includes |
|---|---|
state == "FL" | Florida policyholder notice |
state == "TX" && surplus_lines == true | Texas surplus lines notice |
product == "GL" | General liability coverage form |
additional_insured == true | Additional insured endorsement |
waiver_of_subrogation == true | Waiver of subrogation endorsement |
location_count > 1 | Schedule of locations |
Where the rules come from, and where Mezdoc stops.
Mezdoc does
- Applies the include rule on each document, exactly as your team wrote it
- Fills coverage forms, notices and endorsements from the same policy data
- Writes declarations and schedules that grow with the data
- Merges the packet in your order, with a certificate of completion
- Records which workflow version each run used
Mezdoc does not
- Decide which forms, notices or endorsements a risk legally requires
- Track state filings or form approvals
- Infer a coverage selection your system did not send
- Build the schedule of forms from the packet by itself
- Replace your PAS, AMS or rater
Good to know before you build
- No built-in rule library
- Mezdoc ships no state, carrier or program rules. Your product and compliance teams decide them.
- One signer per submission or run
- Each submission or workflow run is completed and signed by one person. Mezdoc does not route documents to another signer, and has no signing order or countersignature.
- No prebuilt PAS or AMS connector
- Your system calls the REST API, or a person fills the hosted form. There is nothing to install in your PAS.
- New editions need a republish
- A published workflow keeps the template versions it froze. Publish the workflow again to pick up a new form edition.
Questions about policy packet automation.
- Does Mezdoc know which forms a policy needs?
No. Your team configures an include rule on each document, and Mezdoc applies it on every run. Mezdoc has no built-in state, carrier or program rules, and it does not decide which forms a risk legally requires.
- Can one policy packet mix static PDFs and dynamic documents?
Yes. A workflow can hold static PDF templates, such as coverage forms, state notices and endorsements, and dynamic documents, such as declarations and a schedule of forms. They all fill from the same workflow fields and merge into one packet in the order you set.
- How is the schedule of forms produced?
It is a dynamic document your team builds. Its rows can come from a list of forms your system sends, or from IF blocks that read the same fields as your include rules. Mezdoc renders what the schedule template says; it does not compile the list from the packet by itself.
- What happens when a form edition changes?
Upload the new edition as a new template version, test it on staging, then publish the workflow again. A published workflow keeps the template versions it froze, so a live packet never changes underneath you, and every past run records the versions it used.
- How does the finished packet get back to our system?
The workflow run API returns the merged packet and each document. With ?async=true it returns a 202 at once, then sends a signed workflow.run.completed webhook when the run finishes. You can download one document, the merged PDF, or a zip of everything.
Show us one packet you assemble today.
Free plan, no card