Documentation
How the platform behaves, from the first question in an intake to the carrier acknowledgement on a submitted application. One page, so it stays current.
How to read this
One document, ordered the way a case moves, with a table of contents that links to every topic on it.
Solved Enroll keeps one client record across Medicare, life, and ancillary. Almost everything surprising about the platform follows from that single decision, so the documentation is ordered the way a case moves rather than by product.
Start with getting started if you are new to a cohort, or with the worked example if you would rather see one case run end to end before reading anything else. If you are connecting another system, the API reference is the companion to this page and the integrations page describes the shapes those connections usually take.
Solved Enroll is in private beta. Agencies are onboarded in cohorts ahead of a 2027 public rollout. Behavior described here is current; the live carrier list is smaller than it will be at general availability and grows with each cohort. Join the waitlist for the next cohort.
Table of contents
10 categories, 63 topics. Every link below goes to a section of this page.
A worked example, intake to ranked recommendation
One client, one session. The names, values, and identifiers below are illustrative, but the sequence is the real one.
-
Scope of Appointment, then the client record
SOA is captured and timestamped for Medicare Advantage and Part D before the sales conversation starts. The client record goes in next: date of birth, the county she lives in, and her phone number. County rather than ZIP, because the service area is county-level.
-
Intake, with the client reading off bottles
She reads four medications out loud. Three resolve on the first pass, including one read as an abbreviation. The fourth is ambiguous between two strengths, so the platform asks which one rather than guessing, because the answer changes both the drug cost and, on a life case, the underwriting class. She names her cardiologist and the pharmacy two blocks away.
-
Eligibility, then the quote
Entitlement, current enrollment, and the open election period are checked before any plan appears. The quote then applies service area, formulary, and network. Thirty-one plans in the county become five candidates, and the twenty-six that dropped out each carry the reason they dropped.
-
The ranking, and what drove it
The recommender scores the five and returns them in order. The top plan is first because her medications sit on a lower tier and both named providers are in network, despite a slightly higher premium. That sentence is not marketing copy, it is the factor list rendered as English, and it is what the agent says out loud.
-
Signature, submission, and the file
She picks the top plan. The application is prefilled from the quote, so only the handful of fields the carrier needs and the platform does not know are asked for. She signs on the tablet. Submission, acknowledgement, and the whole trail land on the case, and the case file exports as one document. See prefilling an application and exporting the case file.
What the intake produced
POST /clients/cli_8Fq2mR/health-profile
{
"tobacco": false,
"medications": [
{"term": "atorvastatin", "strength": "20 mg"},
{"term": "metformin", "strength": "500 mg"},
{"term": "levothyroxine","strength": "75 mcg"},
{"term": "eliquis", "strength": "5 mg"}
],
"conditions": [
{"term": "atrial fibrillation",
"onset": "2019-04", "control": "controlled"}
],
"pharmacy_id": "phm_22Ge9",
"providers": ["prv_71Km4"]
}
What the recommender returned
{
"id": "rec_3Wd9Lp",
"plan_year": 2027,
"ruleset_version": "2027.04",
"results": [
{"rank": 1, "score": 92, "plan_id": "pln_4ac81b",
"factors": [
{"name": "drug_cost", "effect": 31},
{"name": "provider_match", "effect": 18},
{"name": "premium", "effect": -4}
]},
{"rank": 2, "score": 84, "plan_id": "pln_9de204"},
{"rank": 3, "score": 79, "plan_id": "pln_1bf773"}
],
"excluded_count": 26
}
The same call, with its conventions and error cases, is documented on the API reference.
Getting started
What to do in your first week, and what being in a beta cohort actually changes about the work.
How private beta access works
Agencies are onboarded in cohorts rather than one signup at a time, because the team sits with each cohort through a real selling season and fixes what that season exposes. Cohorts are grouped by product mix and by the states an agency is active in, so the carriers loaded for you are the ones you actually write. Beta access is free for the agencies in a cohort, and beta agencies lock in preferred pricing at general availability. The live carrier list is smaller during beta than it will be at launch, and it grows in the order beta agencies need it rather than alphabetically.
Setting up your profile, licenses, and states
Your resident and non-resident licenses, and the states you are active in, decide what you can quote. Enter them before your first case. A missing state license produces exactly the same screen as a missing plan, which is an empty quote, so ten minutes of setup saves a confusing afternoon later.
Adding your carrier appointments
You only ever see carriers and products you are appointed to write. Appointments are recorded per carrier, per product, and per state, and can be entered by an agent for themselves or loaded by an agency administrator for a whole downline. This is a compliance control, not a preference: it is why the platform cannot start a case an agent is not licensed and appointed to finish. See carrier contracting and appointment records for the agency side of this.
Running your first case end to end
The path is the same every time: capture Scope of Appointment, create or match the client, build the health profile, run the quote, read the ranking and its reasoning out loud, then send for signature. Your first case takes longer because you are reading every screen. By the fourth, the case takes about as long as the conversation does, which is the entire point. Work through the worked example before your first live call if you want to see the shape of it first.
Working across desktop, tablet, and phone
A case is stored server side rather than in the browser, so a fact-find started on a laptop at the office can be finished on a tablet in a living room without re-entering anything. Signing happens on whichever device the client is actually in front of, and switching devices mid-case is a normal thing to do rather than a recovery procedure.
Getting help during beta
Support during beta is case-level. Send the case reference, the carrier and product, and what you expected to happen to contact@solvedenroll.com and you will hear back within one business day. Cohorts also get a direct channel to the team set up during onboarding. The help center lists the categories, and the status page is the first place to look if something platform-wide is wrong.
Client records and intake
One record per person, carrying every line of business and every case you have ever run for them.
Creating a client record
A client record needs a legal name, a date of birth, a county, and a way to reach the person. County is not optional politeness: Medicare service areas are defined at the county level, so a ZIP code that straddles two counties will quote differently depending on which one the client lives in. Records created from a dialer or a CRM can carry your own external reference, so reconciliation later runs against the key your system already trusts.
Households, spouses, and dependents
Two people in a household are two linked client records rather than one record with two names on it. Eligibility, health profiles, and applications are all per person, so combining them would break each of those. The link exists so a spouse quote does not require retyping an address, and so household ancillary coverage can be written without opening a second case from scratch.
Building a health profile
The profile holds height, weight, tobacco use, the medication list, and the condition list. It is the single input that drives both life field underwriting and Medicare drug cost modeling, which is why it is built once per person rather than once per quote. Questions are driven by the carriers still in play: as products drop out, the follow-ups they required stop being asked, so a clean profile takes a fraction of the questions a paper fact-find would.
Entering medications by brand, generic, or abbreviation
Type what the client reads off the bottle. The library covers more than 200,000+ medications and conditions, handles brand and generic names, abbreviations, and ordinary misspellings, and returns the resolved term with its strength and form. When a string is genuinely ambiguous you get a candidate list to pick from rather than a silent guess, because a wrong strength changes a drug cost and a wrong drug changes an underwriting decision. If nothing resolves, record it as a free-text note so the case can continue and send us the exact string.
Recording conditions, dates, and severity
Conditions carry an onset date, current treatment, and control status, because carrier rules almost always turn on those rather than on the diagnosis alone. A condition diagnosed eleven years ago and a condition diagnosed last spring are different cases to an underwriter even when the name is identical. Enter the date you have; if the client is unsure, record the uncertainty rather than a confident guess.
Merging duplicate client records
The same person arrives twice: once from a lead source and once from a walk-in. Merging picks a surviving record and moves health profiles, quotes, applications, and documents onto it. Fields that conflict are reported for you to resolve rather than silently overwritten, and the merge itself is written to the audit trail with who did it and when, so a later reviewer can see that two records became one.
Resuming an unfinished case
Cases stop halfway. A client has to leave, a document is missing, or the appointment runs out of time. Reopening the case puts you back where you stopped, on any device, with the intake and any quote already run still in place. One thing does not resume: a quote whose plan year or carrier rule set has since changed is re-run rather than reused, and the platform tells you it did that instead of quietly showing you last month's prices.
Medicare quoting
Eligibility first, then network and real drug cost, and only then a list of plans.
Checking eligibility and election periods
Before any plan appears, the platform checks entitlement, what the client is currently enrolled in, and which election period is open on the requested effective date. A plan the client cannot elect is excluded with that reason attached rather than shown and then declined by the carrier three weeks later. The lookup is recorded on the case, so the basis for quoting a particular election period is reconstructable during a review.
Quoting MAPD and Part D
Medicare Advantage and standalone Part D quote from the same client record. Inputs are the county, the effective date, the pharmacy the client actually uses, and any providers they named. Plans come back with premium, maximum out of pocket, and the extra benefits clients ask about, alongside the modeled annual drug cost for that specific medication list rather than a generic estimate.
Quoting Medicare Supplement
Med Supp quotes by plan letter, age, tobacco use, and the discounts the carrier publishes. Where the client is outside a guaranteed issue situation and health underwriting applies, the health profile is used the same way it is on a life case, so a plan the client would be declined for does not sit at the top of your comparison. Pairing a Med Supp with a Part D plan is done from the same case rather than as a second quote.
Quoting Special Needs Plans
Dual eligible and chronic condition Special Needs Plans run through the same guided flow, with the additional verification steps those plans require built into it. Because the condition list is already on the client record, a chronic condition SNP the client qualifies for surfaces rather than depending on the agent remembering to check.
Shopping by doctor and pharmacy
Name the doctors and the pharmacy the client will not change, and network status is confirmed against each plan before it reaches the comparison. The comparison then highlights which of those named providers each plan covers, which is a far more useful screen than a network name the client has never heard of. Pharmacy matters twice: once for network status and once for pricing, because preferred, standard, and mail order pricing differ inside the same plan.
Modeling real drug costs
Drug cost is the reason most Medicare recommendations turn out wrong, so it is modeled rather than estimated. For the client's actual list, the platform prices tier placement, prior authorization, step therapy, and quantity limits per plan, then walks the plan year through the deductible, initial coverage, and catastrophic phases at the pharmacy the client uses. Where a therapeutic equivalent would change the annual total materially, it is flagged so you can raise it with the client rather than discovering it in February.
Building a side-by-side comparison
Put two to four plans against each other on the fields that came up in the conversation: premium, maximum out of pocket, dental, vision, hearing, transportation, drug cost, and named provider coverage. The client-facing view hides internal fields so you can turn the screen around, and the whole comparison exports as a PDF leave-behind that goes in the file as evidence of what was actually presented.
Reading the excluded list
Every plan filtered out of a quote carries the reason it was filtered. This is the most useful screen in the product when a plan you expected is missing. The usual reasons are an election period that does not permit it, a county outside the service area, a formulary that does not carry a drug on the list, a named provider out of network, or a carrier your agency is not appointed for. Read the reason before you conclude that something is broken.
Life underwriting
Carrier rules encoded as data, so the products a client cannot get never reach the quote.
How encoded carrier rules work
Carrier underwriting rules are encoded as data and versioned with effective dates rather than kept as a folder of PDFs in somebody's head. When a carrier changes a rule, the change is published as a new dated version, so a quote you ran in March can still be reconstructed against the rules that were in force in March. That versioning is what makes a field underwriting decision defensible six months later, and it is also why the platform can tell you which rule excluded a product.
Knockouts, lookbacks, and build charts
Three kinds of rule do most of the work. A knockout removes a product outright for a condition or a medication. A lookback asks whether something happened inside a window, which is why onset dates and treatment dates matter more than diagnosis names. A build chart compares height and weight against the carrier table for the rate class being sought. All three run before plans are shown, so you are looking at products the client can actually be issued.
Rate classes and tobacco
Quotes are returned at the rate class the profile supports, not at best class with an asterisk. Tobacco definitions differ between carriers in ways that matter: what counts, how recently, and whether occasional use is treated differently. Those definitions are part of the encoded rule set, so a client who used a cigar at a wedding is not quoted as a smoker at every carrier just because one carrier would treat them that way.
Term and whole life
Term quotes take a face amount and a term length, or a target premium, and return the products the profile qualifies for at the class it qualifies for. Whole life quotes the same way with the guarantees and cash value the carrier publishes. Where a carrier offers an accelerated or fluid-free path the profile qualifies for, that is surfaced with the quote, because it changes how long the case takes to issue.
Final expense and preneed
Final expense is quoted as level, graded, or guaranteed issue based on what the health profile supports, which is exactly the distinction that produces chargebacks when it is guessed at. Preneed quoting accounts for the funeral goods and services being funded and the assignment that goes with it. Both lines use the same profile that pre-qualified the client for everything else, so an ancillary or Medicare conversation can follow without a second fact-find.
Build-to-budget quoting
Most final expense conversations start from a monthly number the client can live with, not a face amount. Enter the premium and work backwards: the platform returns the face amount and the product combination that fits it, across the carriers the profile qualifies for. This keeps the conversation on what the client said rather than on what the form wanted.
When a rule disagrees with what you know
You have written this carrier for years and the platform says the client is knocked out. Say so. Send the case and the carrier, and support checks the encoded rule against the carrier guide. Corrections are published as a new dated rule version and go out to everyone, not just to you, which is one of the concrete reasons beta cohorts are small and close to the team.
Ancillary products
Dental, vision, hearing, hospital indemnity, accident, and critical illness, quoted from the record you already filled in.
What the ancillary catalog covers
Six product families: dental, vision, hearing, hospital indemnity, accident, and critical illness. They are the products that round out a Medicare sale and the products a client asks about after a hospital stay, which is why they live in the same platform rather than in a separate portal you visit twice a year.
Attaching ancillary to a Medicare or life case
From an open case, add ancillary products to the same client and the same cart. Nothing is re-entered, the recommendation accounts for what the medical plan already covers, and the signature flow carries both the medical and the ancillary application. The practical effect is that the attach conversation happens at the visit where you already have the client's attention.
Writing ancillary standalone
Ancillary does not require a medical case. Create the client, capture what you need, quote, and enroll. Under 65 dental and accident cases run the same way, so an agent whose book is not Medicare-only is not working around a Medicare-shaped tool.
Reconciling effective dates
An ancillary policy that starts a month after the medical plan leaves the client uncovered for a month, and they will remember. Effective dates are reconciled against the medical plan on the same case, and a gap is flagged before signature rather than discovered by the client at a dental appointment.
Seeing what an attach is worth
Commission structure is visible per carrier and per product before you recommend anything, so an attach decision is made with the economics in front of you rather than from memory. It sits alongside the recommendation, not inside the client-facing comparison view.
The AI Plan Recommender
Ranked rather than filtered, explainable every time, and deterministic so a case can be reconstructed.
How ranking works
Everything the client cannot have is removed first: eligibility, service area, formulary, network, appointment, and underwriting. The recommender then scores what is left and returns it in order. That ordering is the difference between a conversation that starts from a recommendation and a conversation that starts from a spreadsheet, and it is why the excluded list is published separately rather than mixed into the results.
The factors behind a score
Every ranked plan carries the factors that lifted or lowered it, each with its own effect on the score. The common ones are modeled drug cost, named provider coverage, premium, maximum out of pocket, benefit richness in the areas the client raised, underwriting class, and stated budget. A factor list is not a summary of the score, it is the score, which is what makes the ranking reviewable.
Tuning weights for your agency
Agencies weight differently and should. An agency writing mostly dual eligible SNPs does not value premium the way an agency writing Med Supp does. Weighting is set per agency, applies to every agent under it, and is recorded with each recommendation so a ranking produced under last quarter's weighting is still explainable under this quarter's.
Reading an explanation with a client
The explanation is written to be said out loud. "This one is first because your two prescriptions are on a lower tier and both of your doctors are in network, even though the premium is slightly higher" is a sentence a client can follow and challenge. When they ask why the second option is not the first, the explain view shows the factor difference and what would have to change for the order to flip.
Reproducing a past recommendation
The same profile against the same rule set and plan year returns the same ranking. Stored recommendations keep the rule set version, the plan year, and the weighting that were in effect when they ran, so retrieving a recommendation returns the original rather than a fresh ranking that happens to look similar. That distinction is the whole reason the recommender is usable in a compliance review.
Calling the recommender from your own system
The engine an agent sees is the engine the API returns. It is available as a REST endpoint and as an MCP server, so a CRM, a dialer, or an LLM agent runtime can rank plans mid-conversation without rebuilding Medicare and underwriting logic. See the recommendations endpoints, the MCP endpoints, and licensing.
Enrollment and e-signature
From a chosen plan to a signed, submitted, acknowledged application without leaving the session.
Prefilling an application from a quote
The application is populated from the client record, the health profile, and the quote, on the carrier form version that applies. Nothing is transcribed between recommending and enrolling, which removes the step where a transposed date of birth turns into a rejected application. What is left is the short list of fields the carrier needs and the platform does not already know, and those are the only fields you are asked for.
Sending for signature by text, tablet, or email
Three delivery modes, chosen at the moment you need one. A texted link is the only thing that works when the client is on the phone and nowhere near a computer. A tablet handed across the kitchen table opens in signing mode with the agent view hidden. An email suits the client who wants to read it first or wait for a family member. All three produce the same signed document and the same audit trail: delivery method, device, IP address, consent text, and timestamps retained with the document.
Partial saves and resuming a signature
A client who starts signing and stops does not start over. The packet holds partial progress, and a failed delivery can be resent to a different number or switched to another delivery mode without rebuilding it. Practically, this is what turns "I will do it tonight" from a lost case into a case that finishes at nine in the evening.
Submission and carrier acknowledgement
A signed application is transmitted electronically in the format the carrier accepts. Submission state then moves from submitted to acknowledged to a final disposition as the carrier responds, and every transition is written to the case with a timestamp. You can see whether an application is submitted, acknowledged, pending a requirement, or issued without logging into a carrier portal, and the same transitions are available over the API and as webhook deliveries.
Fixing a rejected or incomplete application
When a carrier raises a requirement or rejects an application, the reason lands on the case. Make the correction against the existing case and resubmit, rather than starting a new application: the original trail stays intact, the client does not sign a whole packet again where the carrier does not require it, and a reviewer can see the sequence of what happened. If an application is stuck at the carrier rather than rejected, send the case reference to support and we chase the carrier.
Exporting the case file
One export produces the complete case file as a single document: Scope of Appointment with its timestamp, the disclosures presented and acknowledged, the plans presented, the plan chosen, the recommendation and the factors behind it, the signed application, and the submission and acknowledgement record, in order and with attribution throughout. This is the artifact to produce when a carrier or a reviewer asks, and it is a by-product of the workflow rather than something an agent has to assemble.
Compliance and recordkeeping
The audit trail a carrier or a CMS reviewer asks for, produced by doing the work rather than by remembering to.
Capturing Scope of Appointment
Scope of Appointment is captured before the sales conversation begins, tied to the products it covers, timestamped, and stored on the client record rather than in a separate folder. A missing or expired SOA is surfaced as a blocker at the point it matters instead of being discovered during an audit. Because it lives on the record, it travels with the case file export automatically.
Presenting and logging disclosures
Required disclosures are presented at the point in the workflow the rules call for, and the client acknowledgement is logged against the specific disclosure rather than as a single blanket consent at the end. The record shows which disclosure was shown, when in the conversation it appeared, and that it was acknowledged, which is the level of detail a reviewer actually asks for.
What the audit trail records
Every case action carries an actor and a timestamp: SOA capture, disclosures, intake edits, quotes run and the rule set version they ran against, plans presented, the recommendation and its factors, signature events, submission attempts, carrier responses, document views, downloads, and exports. The trail is built as you work, so nothing depends on an agent writing notes. Security and privacy lists it row by row.
Retention windows and scheduled aging
Two obligations pull against each other: keep enrollment records long enough for the carrier and the state, and do not hold health data longer than you need it. Retention windows are configured per carrier and per state of sale rather than set to one global default, and records age out automatically when their window closes. A record under review or dispute is held past its window deliberately, with the reason recorded.
Who can see what
Visibility follows the hierarchy rather than a flat user list. An agent sees their own book, a manager sees their team, a principal sees their downline, and an agency cannot see another agency at all. What an agent can quote or submit additionally follows their licenses and carrier appointments. Every view of a health profile or a document is logged with attribution, including views by platform staff supporting a case.
Responding to a carrier or CMS review
Export the case file. It contains the Scope of Appointment and its timestamp, the disclosures and acknowledgements, the plans presented and the plan chosen, the recommendation with the factors that produced it, the signed application, and the submission and acknowledgement record, in order. Because plan data and carrier rules are versioned by plan year, a case from a prior year is reviewed against the rules that were in force when it was written rather than against today's.
Agency administration
Hierarchy, licensure, roles, and the dashboards a sales manager runs a week on.
Building your hierarchy
Hierarchy is modeled as the upline and downline structure you already have, not as a flat list of users with a manager field. Nodes carry agents, and visibility, reporting, and dashboards all resolve through the tree. Restructuring a downline changes visibility immediately and is written to the audit trail, because who could see what last quarter is a question that gets asked.
Adding and deactivating agents
Add an agent to a node with their licenses, appointments, and role. Deactivating an agent ends their access without deleting their book: cases, clients, and records stay where they are, reassignable to another agent, because a departed agent does not take a compliance obligation with them. Onboarding flows put guardrails on the first few cases and then get out of the way.
Carrier contracting and appointment records
Appointments are recorded per carrier, per product, and per state, and they gate what each agent can quote and submit. An administrator can load them for a whole downline instead of asking every agent to enter their own. When an agent reports that a carrier is missing, check the appointment record first: most of the time the carrier is live on the platform and the appointment has not been recorded. The agencies endpoints expose the same can-write status so your own systems can check before starting a case. See agency endpoints.
Roles and permissions
Roles are least-privilege by default and scoped to a node in the hierarchy. An agent works their own cases; a manager sees their team and its numbers; a principal sees the downline and the agency configuration; an administrator manages users, appointments, and exports. Permission to see a health profile or a document is granted deliberately rather than inherited from a job title, and every use of it is logged.
Dashboards and scorecards
The funnel runs intake started, quoted, recommended, submitted, issued, broken out by agent, product, carrier, state, and week, from the same live records agents work in rather than from a nightly summary. Agent scorecards show conversion, attach rate, and product mix. The value is spotting the agent whose quoting is fine and whose submissions are not, in week two rather than at month end.
White-label and branding
Running the platform under your own brand and domain is available at general availability for IMO and enterprise agreements, covering the agent interface, the client-facing comparison views, and the signature experience. During private beta the platform runs under Solved Enroll branding. See pricing for how the tiers are structured and agency and IMO for what the tier includes.
Data and exports
Four ways to get your book out, and the rules about what leaves with it.
Scheduled CSV exports
Choose the records and the fields, set a cadence, and collect the file from a secure location. This is the right tool when the receiving system is a spreadsheet or a person. Export runs, and who configured them, are written to the audit trail, and files are held for a short collection window and then deleted rather than accumulating indefinitely.
Pulling records over the API
List endpoints page with a cursor, up to 100 records at a time, and accept a changed_since filter so a nightly job only fetches what moved. Reads use the same permissions and hierarchy scope as the account the token belongs to, so an integration cannot see more than its owner. Do not page a list endpoint to move a whole book; use a warehouse export for that. See the API reference.
Subscribing to webhooks
Webhooks are the fastest way to keep another system current: a signed, timestamped POST within seconds of the event, retried with backoff for up to 24 hours. Payloads are deliberately thin, carrying identifiers and the fields you route on rather than whole documents, so protected health information does not sit in your delivery logs. Verify the signature against the raw bytes before parsing, respond 2xx quickly, and key on the event id because delivery is at least once.
{
"id": "evt_7Hs2Qa",
"type": "application.acknowledged",
"created": "2027-10-16T09:14:52Z",
"data": {
"application_id": "app_0Kd3Vx",
"client_id": "cli_8Fq2mR",
"external_ref": "crm-40219",
"line": "medicare",
"product_type": "mapd",
"carrier_reference": "A-88412706",
"status": "acknowledged",
"requirements": []
}
}
The full event list is on the webhooks section of the API reference.
Warehouse exports
A wider, flatter extract of clients, quotes, recommendations, applications, and case events, shaped for loading rather than for reading. Use this instead of paging a list endpoint when you want the whole book, because it is built for volume and does not compete with live agents for the API rate limit.
Field masking in exports
Medicare beneficiary identifiers and Social Security numbers are masked in the interface and in exports by default, and revealed only where a submission requires the full value. Health data is included in an export only when the export is configured to include it and the requesting role is permitted to see it, which keeps a routine reporting feed from quietly becoming a protected health information feed.
Deleting and aging out data
Records age out automatically when the retention window configured for their carrier and state closes. Deleting on request is possible for data not subject to a retention requirement; records a carrier or a state requires you to keep are retained for that period and then aged out, which is a legal obligation rather than a lock-in tactic. See retention on the security page.
Where to go next
The reference, the people, and the platform state.
API reference
Resource groups, endpoint tables, webhook events, rate limits, and the error format.
Read the referenceIntegrations
How dialers, CRMs, carriers, data feeds, and agent runtimes connect to the platform.
See integrationsHelp center
Topic categories, the questions agents ask in beta, and how to reach a person.
Get helpSystem status
Component state for quoting, pricing, the recommender, enrollment, submission, and the API.
Check statusFAQs
Documentation questions
Why is all of the documentation on one page?
Because it is honest about where the product is. Solved Enroll is in private beta, and a hundred thin article pages that go stale every time a cohort onboards would be worse than one page that is current. The table of contents links to every topic on this page, so you can still land on a single answer.
Does the documentation describe beta behavior or launch behavior?
Behavior, not availability. Everything described here is how the platform works. What differs during beta is the live carrier list, which is smaller than it will be at general availability and grows with each cohort, and white-label, which arrives at launch.
Where do I find field-level API schemas?
The API reference documents the shape of the API: resource groups, endpoints, conventions, events, and the error format. Field lists, enumerations, and sandbox data come with your credentials, because they are still moving while cohorts onboard and publishing a stale schema is worse than publishing none.
A screen does not match what this page says. Which is right?
Tell us and we will fix whichever one is wrong. During beta the product moves faster than a documentation page, so a mismatch is a genuine bug report rather than a nuisance. Email contact@solvedenroll.com with the screen and what you read here.
Is there a sandbox to test against?
Sandbox credentials and test client data are issued with API access, through cohort onboarding or a licensing conversation. There is no self-service sandbox signup, because tokens reach protected health information and Medicare beneficiary data.
Something else? Contact us
Something here not match what you see?
Beta agencies find the gaps first. Send the screen and what you read, and we will fix whichever one is wrong.