How this connects
Two directions. What Solved Insurance will use from inside its own group, and what an outside partner could integrate against. Both described as protocols rather than as announcements.
Two directions, and one thing this page is not
An integrations page is usually a logo wall. This one is a list of protocols.
Solved Insurance sits at the end of a chain the same group already owns: demand at Solved Marketing, the conversation at AgentTech Dialer, quoting and enrollment at Solved Enroll, contracting at Solved Solutions. That is the first direction, and it is why a different cost structure is arguable rather than aspirational.
The second direction is outward. A few interfaces in the group can be licensed by companies outside it, and they are listed below with links to the owners who credential them.
What this page does not do is claim partnerships. Nothing here is a certification, a carrier endorsement, a marketplace listing, or an announcement about any insurer, reinsurer, or rating agency. Where a system is named, the claim is only that the protocols line up.
Solved Insurance products are in development and pending state approval. Nothing on this site is an offer of insurance, and the connections described here describe design intent and protocol compatibility rather than live integrations for an approved product. Join the waitlist to hear when coverage opens in your state.
Inside the group
Four companies, one chain. The stage label on each says honestly what is running today and what is not.
Solved Marketing, for demand
Operating
Owned lead acquisition, generated in house rather than bought from an aggregator. Final expense intent is its largest program, which is the practical reason this product line exists at all. Records arrive on submission rather than in nightly batches, either natively into a dialer campaign or an enrollment client record, or over an HTTP post or a webhook.
Why it is in the chain. Removing the lead aggregator margin is one of the three reasons a different price is arguable rather than aspirational.
AgentTech Dialer, for the conversation
In production
The dialer, CRM, and compliance scoring the group already runs its own calling on, in production with paying customers inside and outside the group. It holds the contact record, the call outcome, the recording, and the compliance evidence for the conversation, and exposes all of it over a REST API with signed webhook deliveries.
Why it is in the chain. Most people buying final expense coverage want to talk to somebody. The conversation is part of the product, so the software that carries it is too.
Solved Enroll, for quoting and enrollment
Private beta
Multi-product quoting and one-session enrollment with electronic signature delivered by text, tablet, or email. It also operates the AI Plan Recommender, which runs the same comparative underwriting core, as a REST API and a Model Context Protocol server.
Why it is in the chain. A decision that cannot be signed in the same session is not a one-session experience, whatever the underwriting does.
Solved Solutions, for contracted distribution
Operating
The field marketing organization inside the group. It holds agent contracting, appointments, hierarchy, and commission administration, and recruiting for the Solved Insurance launch roster runs through it ahead of product approval.
Why it is in the chain. A product with no contracted field force on the day it is approved has to build one from zero. This is how that is avoided.
Solved Insurance itself is in development and pending state approval, so its own position in this chain is design rather than production. See the status page.
What the chain does to a case
Same case, four handoffs, one record. The point of owning each step is that nothing is re-keyed and nothing is lost between systems.
- DemandA final expense inquiry is generated in house, with the consent language, timestamp, and page stored against the record.
- ConversationThe record lands natively in a dialer campaign, and the call outcome, recording, and compliance evidence attach to it.
- DecisionComparative underwriting evaluates the case across available products together, and returns a decision with the factors behind it.
- EnrollmentElectronic signature is delivered by text, tablet, or email in the same session, with the consent and completion recorded alongside the document.
- ServicingThe same client record stays attached to the policy, so a beneficiary is not asked to explain it again later.
Describing the chain is describing design intent for a product that is pending approval, not a live production path. See how it works
What an outside partner could integrate
Four things, all of them protocol-level. Each is licensed and credentialed by the company that owns it.
AI Plan Recommender over REST
Submit an applicant profile and receive a ranked set of plans with the factors that lifted or lowered each one. Bearer-token auth over HTTPS, JSON in and out, idempotency keys on writes. Licensed and credentialed by Solved Enroll rather than here.
Licensing at Solved EnrollAI Plan Recommender over MCP
The same service exposed as a Model Context Protocol server, so an agent runtime can call it as a tool instead of treating it as a separate integration. If your stack already speaks MCP, this is configuration rather than a build.
Licensing at Solved EnrollE-signature delivery
A signature request delivered to an applicant by text, tablet, or email, with the delivery method, the consent text, the device, and the completion recorded alongside the document. Driven over the same REST conventions, with completion arriving as a signed callback.
Open Solved EnrollData export
Records pulled over an API by cursor, or pushed on a schedule to object storage or an HTTPS endpoint you name. Export files are written as complete sets per window, so a warehouse can load on the window rather than on a file timestamp.
See the conventionsEverything named on this page describes protocol-level compatibility. It is not a claim of a partnership, a certification, a carrier endorsement, a reseller agreement, or a marketplace listing with any organization mentioned. See for partners and developers for the conventions and what is not available.
What you will not find on this page
Five claims a pre-launch insurance brand has no business making, listed so you can check we did not make them.
- No carrier or reinsurer names. Not one, anywhere on this site.
- No rating agency references. We have no rating history, and implying one through association would be worse than having none.
- No certifications or attestations. Security and privacy work is described as a program, with audit readiness work underway. See security and privacy.
- No marketplace listings or badges. A logo on a page is not an integration, and neither is a directory entry.
- No live integrations for an unapproved product. The chain described above is design intent until a product is approved.
FAQs
Integration questions
Does naming a system here mean you have a partnership with it?
No. Everything on this page describes either a company inside the same group or protocol-level compatibility: the system can call a REST endpoint, speak Model Context Protocol, receive a signed webhook, or accept an export. None of it is a claim of a partnership, a certification, a reseller agreement, a marketplace listing, or an endorsement by anybody.
Which carriers and reinsurers are you working with?
We do not name carriers, reinsurers, or rating agencies on this site. A relationship that is under discussion is not a relationship you should read about on a marketing page, and a product that is pending approval has nothing to announce. When there is something signed and real, it will be said plainly.
Can I connect something to Solved Insurance today?
Not to Solved Insurance itself. There is no consumer API and the underwriting API is in development and not generally available. What you can license today belongs to sister companies: the AI Plan Recommender from Solved Enroll, the AgentTech Dialer API, and lead delivery from Solved Marketing.
Why is the integration list so short?
Because a long list would be invented. A pre-launch insurance product does not have a connector directory, and publishing one would be the exact kind of claim this site is trying to avoid. The list will grow when the integrations are real.
Do I need a developer to use any of this?
For the REST interfaces, yes, or at least someone comfortable with an authenticated HTTPS request and a signed webhook. For the MCP server, considerably less: a runtime that already speaks Model Context Protocol treats it as a tool. For contracted distribution through Solved Solutions, no developer is involved at all.
Who handles credentials?
The company that owns the interface. Solved Enroll issues credentials for the recommender and for e-signature, AgentTech issues them for the dialer, and Solved Marketing sets up lead delivery. Across all of them, access comes from a conversation rather than a self-serve key generator.
Something else? Contact us
Tell us what you run.
Describe the systems and the data that would need to move, and we will tell you which of these interfaces exists today.