document generation for insurance core platforms, policy admin systems and in-house stacks
Insurance document generation API for carriers and MGAs.
Your core system is fine. Your document templates are the problem. Policy documents kept as Liquid or Velocity template files can only be changed by engineers, and only through a deploy.
Policy data from your core system becoming an assembled packet
- edited by
- Compliance and operations, in a visual editor rather than a repository.
- released by
- Publishing a template version, pinned per environment. No application deploy.
- owned by
- Your core system. It stays the system of record and Mezdoc stores no policy data.
how documents get stuck
Follow one sentence through a stack that keeps its documents in code.
01 / the point
One sentence. Nine words to change.
A state updates how a wildfire notice must be worded. Someone in compliance knows exactly what the new sentence should say. They are accountable for it, and in most stacks they cannot change it.
02 / what it really is
Because it is not a sentence. It is source code.
In a lot of insurance stacks the notice is markup in a template file, wrapped in a condition, reading policy data through a path. The wording and the logic live in the same place, and that place is a repository.
03 / who works this way
This is documented, not alleged.
Socotra's own documentation describes document templates as HTML and CSS with embedded Liquid, in files named *.template.liquid. Plenty of in-house stacks landed in the same shape on purpose. Some large suites did not, and ship visual authoring instead.
Read the Socotra write-up, with the docs cited04 / what it costs
Four people and a release, for nine words.
The edit becomes a ticket, then a pull request, then a review, then a deploy, then a render to check it worked. Every gate is reasonable on its own. Together they are why the notice is still wrong at renewal.
05 / the other way
The person who owns the sentence changes the sentence.
The wording lives in a template, the condition lives on the document, and publishing a version is the whole release. Compliance edits, test renders, publishes. Your core system keeps the policy data and never notices.
Try it with a different request.
Compliance wants one line on the California wildfire notice reworded before renewals go out.
Documents as template files
6 steps- 01File a ticket for the engineering team
- 02Find the notice inside the template file
- 03Edit the markup, open a pull request
- 04Wait for review
- 05Deploy the configuration
- 06Render a policy to check the result
needs
waits on a release window
Documents in Mezdoc
3 steps- 01Open the template and edit the sentence
- 02Test render with sample data
- 03Publish the version
needs
live when they publish it
Illustrative, and step counts vary by team. The part that does not vary is which roles each path requires.
What it costs to keep documents in code.
- Only engineers can edit
- The person accountable for a disclosure's wording is the one person who cannot change it. They file a ticket instead.
- Every edit is a deploy
- A nine-second sentence change waits on a pull request, a review and a configuration deploy before anyone sees it rendered.
- Document releases ride app releases
- Template versions live in the platform's deployment pipeline, so you cannot roll back a notice without rolling back everything around it.
- The same rules, written twice
- Inclusion logic ends up duplicated between the template language and the system that decides which documents apply.
- Slow feedback on renders
- Checking a conditional branch means producing a render, which makes edge cases expensive to verify and easy to skip.
- Regulators do not use your calendar
- A state changes a notice and the fix needs a release window. Multiply by every state and carrier form you issue.
Which of these is your stack?
Socotra
cloud core platform
Its documentation describes document templates as HTML and CSS with embedded Liquid, in *.template.liquid files that read policy data through a structured snapshot. Changing wording is a code edit and a configuration deploy.
Read the worked exampleIn-house renderers
hand-rolled stacks
A templating library and headless Chrome, built because nothing off the shelf fit. The best fit for this page: the same problem, no vendor to migrate away from, and usually one engineer who has become the document team.
The mapping table below covers every construct
Spreadsheets and shared drives
no system at all
Word files on a drive, each a copy of the last one, with the conditions living in somebody's head. No deploy to wait for, but no versions and no record of which document went out.
Start from a template instead
On the other core platforms
Mezdoc works alongside any system that can make an HTTP request, so the platform you run is not the question. The question is whether the people who own your document wording can change it without a release. If your platform already gives them that, you do not need this page. If you are on a platform we have not written about and the answer is no, tell us which one and we will look at its document layer properly before we say anything about it in public.
Every template construct, and what replaces it.
| In a template file | In Mezdoc | What changes |
|---|---|---|
| data | ||
data.policy.characteristics[0].gross_premium | gross_premium | A field alias, mapped once per template |
{{ variable }} | Variable chip | Inserted in the editor, validated against the field list |
| currency, | date filters | Field formatting | Format is a property of the field, not a filter call |
| logic | ||
{% if %} / {% elsif %} / {% else %} | IF / ELSE block | One condition language across every surface |
{% for item in list %} | FOR EACH block | Repeats a row or a section over a list |
Hand-written visibility checks | Field visibility condition | Same expression syntax as the document rules |
| assembly | ||
{% include "snippet" %} | A document in a workflow | Promoted to its own template with an include rule |
Conditional document selection code | Include or exclude expression | Lives on the document, not inside another template |
Merge or consolidation step | Workflow output | One merged PDF or separate files, configured per workflow |
Pre-rendered static attachment | Fillable PDF template | For carrier forms whose layout must not re-flow |
| release | ||
Config deploy to publish a change | Publish a template version | No application deploy involved |
Platform pipeline environments | Staging and production pins | A workflow pins each document to a version |
Render to check a branch | Test render with sample data | Instant, and free on every plan |
One call, from the system you already have.
Whatever runs your policies keeps running them. It sends the policy data; the workflow applies the rules your team configured and returns the documents.
- Your platform stays the system of record. Mezdoc stores no policy data of its own.
- You bring the carrier forms and the notice wording. Mezdoc fills and assembles them.
- Idempotency keys on renders, HMAC-signed webhooks on completion.
- Every run records the workflow version and a SHA-256 of the delivered documents.
curl -X POST "https://api.mezdoc.com/api/v1/workflows/policy_packet/runs" \
-H "Authorization: Bearer $MEZDOC_API_KEY" \
-d '{ "data": { "state": "CA", "coverage_a": 750000, "mortgagee": true } }'Where this is the wrong answer.
You need a core platform
Mezdoc does not rate, underwrite, bind or administer policies. If the gap you are filling is a policy admin system, this is not it.
Your templates are stable
If the wording rarely changes, your template count is small and your engineers do not mind the requests, the migration cost is paid for nothing.
You want a one-click import
There is no Liquid or Velocity converter today. Each template is rebuilt by hand, so the work scales with how many you have.
Questions from platform and operations teams.
- What is a document layer?
A document layer is the part of an insurance stack that turns policy data into the documents a policy needs: the declarations page, the base form, the endorsements, state notices and any signature on them. In many stacks it is not a separate thing at all, it is template files inside the core platform or a hand-rolled renderer. Pulling it out means the core system keeps the policy data and calls a document service to produce the packet.
- Do I have to replace my policy admin system?
No, and that is the point. Mezdoc is a document generation, assembly and signature layer, not a policy admin system, a rating engine or an underwriting system. Your core platform stays the system of record. It POSTs the policy data to a Mezdoc workflow and gets the assembled packet back, so there is no re-platforming and no second source of truth for policy data.
- How do Liquid or Velocity templates map to Mezdoc?
Variable tags become variable chips, if and elsif blocks become IF and ELSE blocks, for loops become FOR EACH blocks, and an included snippet usually becomes its own document in a workflow with an include rule on it. Verbose data paths collapse to field aliases, and custom formatting filters become formatting on the field. The mapping table on this page lists each construct and its equivalent.
- Is there an automatic template importer?
Not today. Migrating a template is a manual rebuild in the editor, so the effort is real and scales with how many templates you have. The usual order is to move one document set first, confirm the output matches byte for byte where it has to, then work through the rest.
- Which core platforms does this work with?
Any system that can make an HTTP request, because the integration is a POST of policy data and a packet in response. The platform you run matters less than whether the people who own your document wording can change it without a release. Socotra is the one platform we have written about in detail, because its documentation describes documents as HTML and Liquid template files. Several large suites ship visual template authoring instead, so there is no general rule that a core platform forces hand-coded documents.
- Who can edit documents after the migration?
Whoever owns the wording. Templates are edited in a visual editor rather than a repository, so compliance and operations can reword a notice, swap a logo or change a condition without an engineer and without a deploy. Each template and workflow has its own published version per environment, so an edit to a draft cannot reach production until someone publishes it.
Send us one template and we will map it.
Free plan, no card