For partners and developers
There is no public consumer API here, and the underwriting API is not generally available. What follows is what exists today, where it lives, and the shape of what is being built.
What this page is, and is not
A developer page on a pre-launch insurance site is usually fiction. This one tries not to be.
Solved Insurance does not publish a consumer API. There is no endpoint that quotes a policy, no endpoint that takes an application, and no developer signup, because there is no approved product behind any of it.
What does exist is a set of interfaces operated by sister companies in the same group, which are real, in production, and licensed by the companies that own them. Those are documented below with links to their owners. Separately, an underwriting API is in development for carrier and reinsurance partners, and this page describes what a partner integration would involve at the level of shape rather than specification.
Everything here is either pointing you somewhere real or telling you plainly that something does not exist yet. Nothing on this page is generally available, and nothing on it can be self-provisioned.
Solved Insurance products are in development and pending state approval. Nothing on this site is an offer of insurance, and the interfaces described here are not generally available. Start a partner conversation if you are evaluating an integration.
Available today, from elsewhere in the group
Three interfaces you can actually license and call. Each one is owned and operated by the company named on the card, not by Solved Insurance.
AI Plan Recommender
The comparative underwriting core, exposed as a service. Submit an applicant profile and receive a ranked set of plans with the factors that lifted or lowered each one. Available as a REST API and as a Model Context Protocol server, so an agent runtime can treat it as a tool rather than as an integration project.
Licensing details at Solved EnrollAgentTech Dialer API
The dialer and CRM the group runs its own calling on, in production with paying customers inside and outside the group. Drive campaigns and contacts, read call outcomes and recordings, and receive call progress as signed webhook deliveries.
Open AgentTech DialerLead delivery
Owned demand delivered on submission rather than in nightly batches, either natively into a dialer campaign or an enrollment client record, or to an HTTP endpoint or webhook you name. Consent details captured at acquisition travel with the record.
Open Solved MarketingLicensing, pricing, and credentials for each of these are handled by the company that owns it. See also how this connects for what Solved Insurance intends to use from inside the group.
The underwriting API, in development
Being built for carrier and reinsurance partners rather than for the public. Three moving parts, described at a level a technical evaluator can assess.
Case submission
A partner submits a case: the applicant profile, the answers collected, the product context, and the identifiers the partner uses on its own side. Submissions are idempotent, so a retried request produces the same case rather than a duplicate.
A decision response with factors
The response carries a decision, the product context it applies to, and the factors behind it. Factors are the part that matters: a decision a compliance function cannot account for is not usable in a regulated product, and a decision with reasons attached can be reviewed, corrected, or used to route the case somewhere better.
Status callbacks
Anything that completes after the initial response arrives as a signed callback to an endpoint the partner registers: a case reaching a terminal state, a requirement raised, or a referral to a different product. Deliveries are retried, so consumers key on the event identifier and discard duplicates.
In development means in development. There is no sandbox, no token, and no schema to generate a client from. See what is actually running
An illustrative shape
The two payloads below are illustrative only. They are written to show the shape of a submission and a decision, and they are not a specification, not a live endpoint, and not field names to encode against.
Illustrative case submission, not a specification
POST /v1/underwriting/cases
Authorization: Bearer PARTNER_TOKEN
Idempotency-Key: 7f1c9a2e-4b60-4e19-9c2f-0d3a
Content-Type: application/json
{
"partner_case_ref": "case-illustrative-0001",
"product_context": "final_expense_simplified",
"applicant": {
"state": "STATE_CODE",
"age_band": "BAND",
"tobacco": false
},
"responses": [
{ "question_ref": "QREF_A", "answer": "no" },
{ "question_ref": "QREF_B", "answer": "managed",
"recency_band": "BAND" }
],
"callback_url": "https://partner.example/hooks/uw"
}
Illustrative decision response, not a specification
HTTP/1.1 200 OK
Content-Type: application/json
{
"case_id": "CASE_ID",
"partner_case_ref": "case-illustrative-0001",
"product_context": "final_expense_simplified",
"state": "pending_review",
"decision": "refer",
"factors": [
{ "ref": "FACTOR_A", "direction": "adverse",
"basis": "recency_band" },
{ "ref": "FACTOR_B", "direction": "favorable",
"basis": "treatment_stability" }
],
"referral": { "product_context": "ALTERNATE" },
"evidence_ref": "EVIDENCE_ID",
"request_id": "REQUEST_ID"
}
The values above are placeholders on purpose. No product context, question reference, factor reference, or decision value shown here corresponds to a real product, and no underwriting rule, threshold, or knockout condition is published anywhere on this site.
Conventions across the group
Six things hold across the interfaces the group already operates, and the underwriting API is being built to the same conventions.
Bearer-token auth over HTTPS
Every request carries an Authorization header with a bearer token, over TLS, and nothing is accepted over plain HTTP. Tokens are scoped to one account and one integration, issued per integration so revoking one does not break the others, shown once at creation, and stored hashed.
JSON bodies and stable field behavior
Requests and responses are JSON. Timestamps are RFC 3339 in UTC. Fields are added over time and are not removed without notice, so parse defensively and ignore keys you do not recognize.
Idempotency keys on writes
Send an idempotency key on any write. A repeat of the same key returns the original response instead of creating a second resource. Generate one key per logical operation rather than per HTTP attempt, and reuse it across retries.
Webhook signature verification
Each delivery carries a timestamp and a signature computed over the timestamp and the raw request body, keyed with your endpoint secret. Verify against the raw bytes before parsing, compare in constant time, and reject anything outside a short tolerance window so a captured request cannot be replayed at you later.
Standard status codes and a single error envelope
Success codes in the 200 range, 4xx for something the caller can fix, 5xx for something on our side. Errors carry a machine-readable type and code alongside the human-readable message, plus a request identifier worth quoting when you report a problem.
Credentials come from a conversation
There is no self-serve key generator anywhere in this group, and that is deliberate. Access to underwriting decisions, applicant data, or lead delivery is opened by a person after a partner conversation, with scope agreed in advance.
Credential handling, encryption, and incident response are described on the security and privacy page.
Nothing here is self-provisioned
Four things worth knowing before you plan an integration around any of this.
- Credentials come from a conversation. Scope is agreed in advance and issued per integration, so revoking one does not break the others. See the conventions.
- The underwriting API is not available. No sandbox, no token, no schema. See the underwriting API for what is being built.
- The interfaces that exist belong to sister companies. License them from their owners, listed under available today.
- No partnership is implied. Describing a protocol is not a claim of a partnership, a certification, or an endorsement by anybody.
FAQs
Partner and developer questions
Is there a consumer API?
No. There is no public API on this site, no developer signup, and no way to quote or apply programmatically, because there is no approved product to quote or apply for. If you found this page looking for a quoting API, the honest answer is that it does not exist yet.
Can I get access to the underwriting API?
Not today. The underwriting API is in development for carrier and reinsurance partners, and it is not generally available. This page describes what a partner integration would involve so that a technical evaluator can see the shape of it, and the example payloads are illustrative rather than a specification you can build against.
What can I actually use today?
Three things, none of which belong to Solved Insurance. The AI Plan Recommender is available as a REST API and an MCP server from Solved Enroll. AgentTech Dialer has a REST API and webhooks, and is in production. Solved Marketing delivers leads over HTTP post or webhook, natively into a dialer campaign or an enrollment client record. Each one is licensed by the company that owns it.
Are the example payloads on this page real?
No, and they are labeled as illustrative in place. They exist to show the shape of a case submission and a decision response, not to document field names you should encode against. Authoritative schemas would come with credentials, and credentials come from a partner conversation.
How would credentials be issued?
By a person, after a conversation about what the integration is for, what data moves, and what the scope should be. No self-serve key generator exists anywhere in the group for these interfaces, because a token that can read applicant information or produce an underwriting decision is not something to hand out from a signup form.
Does the AI Plan Recommender work over MCP?
Yes. It is offered as both a REST API and a Model Context Protocol server, which means an agent runtime can call it as a tool instead of treating it as a separate integration. Licensing and access are handled by Solved Enroll rather than here.
Who do I talk to about a partner integration?
Start at the contact page and say what you are evaluating and what would need to move between systems. Partner conversations cover the product design and its intended market, the underwriting method and how decisions are evidenced, data handling expectations, and the technical shape of an integration.
Something else? Contact us
Evaluating an integration?
Tell us what would need to move between systems and we will tell you what exists today and what does not.