The Building Block Principle: Why Headless Infrastructure Changes What Carriers and Distributors Can Build
The picture on the lid is a suggestion, not an instruction. The same blocks that build the tower can become a bridge, a city, or whatever the builder wants next.
For decades, carriers and distributors bought what came in the box. A fixed interface, a defined workflow, one way to quote, apply, submit, and service. Want a different experience? Buy a different platform. Want to embed annuities inside an advisor workstation? File a request. Want to adapt as AI reshapes the workflow? Wait for the next major release.
Recently, Zinnia released foundational tools that work differently. Starting with order entry, Zinnia's headless architecture exposes seven core insurance functions as composable APIs — lead submission, illustration and quoting, suitability, digital application, document generation and e-sign, application submission, and in-force servicing.
Each capability works independently and connects to the next, without assuming anything about the experience layer on top.
That sounds like a technical statement. It is not. It is a statement about what carriers, banks, and IMOs can now build.
A bank wants to embed quote-to-apply inside its existing advisor desktop, branded as the bank, with no Zinnia logo anywhere on the screen. Build it. An IMO wants to ship its own producer experience optimized for the way its agents actually sell. Build it. A carrier wants the turnkey Zinnia interface because internal development bandwidth is finite, and the priority this year is volume, not differentiation. Build that too.
Some of those builds look like traditional UIs running on top of the APIs. Some look like advisor-embedded experiences. And some, increasingly soon, will look like nothing at all, because an AI agent will do the work the UI used to require. The blocks are the same. The build is whatever the buyer needs.
The product is what becomes possible when you stop telling people what to build.
The blocks are ready. What gets built with them is up to you.
Pick the Goal.
Each business outcome maps to a defined combination of headless APIs. Start where the pain is greatest and continue to build on success. The infrastructure underneath stays the same.
| Possible Business Outcomes | APIs Required |
|---|---|
| Respond to inquiries before interest cools. Send researched, qualified, and scored leads instantly to a salesperson to call. | LeadIllustration |
| Reduce quote-to-app drop-off. Compress the time between illustration and application. | LeadIllustrationSuitabilityApplication |
| Address NIGO and back-office rework. Auto-generate documents from validated data, include e-signature, and reach the carrier with fewer errors. | LeadIllustrationSuitabilityApplicationDocumentsSubmission |
| Streamline back-office servicing. Reduce the costs and dissatisfaction of rekeying data, tracking status, and fielding needless calls. | In-Force |
| Strengthen the long-term customer relationship. Retain the relationship end to end, from the first quote through years of in-force servicing. | LeadIllustrationSuitabilityApplicationDocumentsSubmissionIn-Force |
| Prepare for agentic workflows. Let AI agents run the workflow directly against the APIs, with no new interface to build. | All seven |
Note: Future workflow models may incorporate AI-enabled automation, subject to carrier requirements, regulatory obligations, supervision frameworks, and compliance controls. The underlying APIs are designed to support flexibility in how experiences are constructed, while allowing carriers and distributors to determine the governance model appropriate for their business. Outcomes are illustrative and depend on implementation, product, distribution model, and regulatory requirements.