The CMS Marketplace API is the same data source behind every consumer-facing ACA plan comparison product built on the federal exchange. What separates a useful product from a thin data wrapper is what the engineering team builds around the data: APTC math, CSR eligibility logic, plan recommendation scoring, intake workflows, and the UX that makes any of that usable by a broker or a consumer in under two minutes. The data itself is not the differentiator.
Key Takeaways
- The CMS Federally Facilitated Marketplace API provides real-time plan data, premium rates, and cost-sharing details for any county and coverage year. It is the data source behind every consumer-facing ACA plan comparison product on the federal exchange.
- Two layers define ACA technology products: the quoting layer (plan comparison, APTC math, plan recommendations) and the enrollment layer (submitting applications to Healthcare.gov). Only the enrollment layer requires CMS EDE certification.
- Most insurtech ACA products fall into one of three categories: consumer-facing plan finders, broker-facing quoting tools, or call center platforms. The API serves all three, but the compliance scope and UX requirements are different for each.
- The maintenance burden on ACA API products is higher than most builds initially budget for. CMS refreshes plan and premium data annually, occasionally updates mid-year, and EDE entities face annual recertification requirements.
- Custom ACA builds are defensible for insurtechs with a specific vertical need: ICHRA administration, embedded insurance products, call centers processing hundreds of enrollments per day, or state-based exchange operators. For general ACA broker quoting, QuoteTurbo is free and covers the quoting layer without a build.
What the CMS Marketplace API actually provides
The Federally Facilitated Marketplace API returns plan data, premium rates, cost-sharing parameters, and network summaries for every county in a given coverage year. A developer with API access can retrieve every plan available in a ZIP code, the full premium schedule for any household configuration, the cost-sharing structure for each plan, and the SLCSP benchmark used to calculate APTC.
That data set powers three types of products: consumer-facing plan finders that help individuals compare options, broker-facing quoting tools that display plans with APTC applied and generate client-ready output, and call center platforms that embed the comparison into a structured intake workflow. The API itself does not care which product is being built. The engineering decisions around it are what shape the product.
One thing the API does not do: submit enrollments to Healthcare.gov. The quoting and comparison layer is accessible to any developer. The enrollment layer requires a separate CMS process.
The two product layers every insurtech needs to separate
Most ACA insurtech builds conflate quoting and enrollment at the start. That conflation is where timelines and budgets go wrong. The two layers are genuinely different products with different compliance requirements and different build timelines.
| Dimension | Quoting layer | Enrollment layer |
|---|---|---|
| Function | Plan comparison, premium display, APTC/CSR math, plan recommendation | Submit enrollment applications directly to Healthcare.gov on behalf of the consumer |
| CMS approval required | No. API access is available to any registered developer. | Yes. Enhanced Direct Enrollment (EDE) certification from CMS is required. |
| Time to build (first version) | 3 to 6 months for a focused product team | 12 to 24 months including CMS review, testing, and certification |
| Annual maintenance | Plan data refresh, API versioning updates, APTC table changes | All quoting layer maintenance plus annual EDE recertification, audit logs, and CMS compliance reviews |
| Compliance scope | Limited to CMS data use policy and standard software security practices | FFM data use policy, Marketplace Privacy and Security rules, annual recertification, MPMS testing |
| Best suited for | Plan finders, broker quoting tools, ICHRA benefit modeling, embedded comparison widgets | Direct-to-consumer enrollment portals, EDE partner platforms, state exchange technology vendors |
The practical implication: an insurtech building a consumer-facing plan finder that routes users to Healthcare.gov for the final enrollment step does not need EDE certification. They build the quoting layer, hand off at the enrollment step, and avoid the 12 to 18 month CMS certification process. Many insurtechs take this path because it gets a product to market faster and avoids the compliance overhead until there is a specific business reason to own the enrollment step.
For a deeper look at what EDE certification involves and when it makes sense for smaller operators, read what is EDE certification and is it worth it for solo agents.
Where legacy tools left gaps that modern insurtechs fill
Tools like Quotit and the legacy Connecture platform were architected before the current CMS API reached its current state. Both were built on earlier data infrastructure with different integration patterns. Modern insurtechs starting a build today have cleaner API access, better documented endpoints, and the ability to implement APTC and CSR logic in their own stack rather than inheriting a layer-on-layer migration from 2014 architecture.
The gap that most new builds fill is not plan data coverage. The federal API handles that. The gaps are in workflow: intake that captures the right income and household data, plan recommendation logic that surfaces the Silver CSR options for clients who qualify, PDF output that looks like the agency's brand, and CRM integration that logs the quote alongside the client record. Those layers are engineering decisions, not API limitations.
The three use cases where a custom build is the right answer
Most insurtech ACA API builds fall into one of three categories. The right build decision depends on which category the product fits.
ICHRA administration. Individual Coverage HRA administrators need to model employer contribution levels against the SLCSP benchmark for affordability testing, surface individual plan options for employees by their county, and calculate employee cost exposure. The quoting API serves the plan data need, but the ICHRA affordability logic sits on top of it in custom code. General broker quoting tools do not model this correctly for ICHRA use cases.
Call center platforms with 100-plus agent operations. A call center quoting 200 enrollments per day needs intake workflow automation, SOA compliance logging, CRM write-back, and reporting that surfaces agent performance against enrollment targets. Those product requirements are outside what a general quoting tool supports. The API provides the plan data layer; the custom build provides the operational layer.
Embedded insurance products.Fintech, payroll, and benefits platforms that want to surface ACA options as part of a broader product experience need to embed the plan comparison inside their own UI. QuoteTurbo is a standalone tool. An embedded experience requires an API integration into the host platform's design system and authentication context.
For agencies evaluating whether to build or buy, the honest break-even question is whether the specific need can be served by a free quoting layer versus a custom build. Read should your agency build its own ACA quoting tool for the break-even calculation.
The maintenance burden most builds underestimate
ACA API products are not build-once assets. CMS publishes new plan year data every fall. That data refresh requires updating every plan record, re-testing all premium calculations against the new rates, verifying that APTC and CSR logic reflects any regulatory changes, and validating that the product output is accurate before AEP opens.
Teams that staff the initial build at three engineers often find that the annual refresh requires two of them for six weeks before every AEP. EDE entities add recertification requirements on top of the data refresh. A product that works correctly in November 2025 does not automatically work correctly in November 2026. The maintenance contract is part of the build budget.
This is one reason Devkrest, the engineering team behind QuoteTurbo, runs the plan data refresh as an operational process. Any agency or insurtech using QuoteTurbo gets the updated plan year data without managing the refresh themselves. The question for a custom build is whether owning that process is worth the ongoing engineering cost.
FAQ
Common questions from insurtech and agency teams evaluating ACA API products.
Who can access the CMS Marketplace API?
The CMS Marketplace API is available to any registered developer. Access to plan and premium data for display and comparison purposes does not require CMS approval beyond standard API registration. The enrollment layer, which allows submitting applications directly to Healthcare.gov, requires Enhanced Direct Enrollment certification. Most insurtech product teams use the API for quoting and display without pursuing EDE certification, either completing enrollment through a certified EDE partner or directing users to Healthcare.gov for the enrollment step.
What is the difference between a plan finder and an EDE platform?
A plan finder compares plans, displays premiums, applies APTC math, and may recommend plans based on household characteristics. It does not submit enrollment applications. An EDE platform does all of the above and also submits enrollment applications directly to Healthcare.gov on behalf of the consumer, without routing the consumer through the Healthcare.gov interface. EDE requires CMS certification, an annual recertification process, and compliance with CMS data security and privacy requirements.
How often does CMS update its plan and premium data?
CMS publishes updated plan and premium data for each plan year before the AEP window opens, typically in October. This annual refresh requires every ACA API product to update its plan database, re-test pricing calculations, and verify that APTC and CSR logic reflects any regulatory changes for the new plan year. Mid-year plan data changes can also occur if a carrier exits a market or if CMS revises plan information. ACA API products need a documented refresh and testing process, not just a one-time build.
What does EDE certification actually require?
EDE certification from CMS involves application review, security and privacy compliance documentation, a testing period with CMS oversight, and final approval before an entity can submit enrollments to Healthcare.gov. The process typically takes 12 to 18 months from initial application to live certification. Annual recertification is required. Entities pursuing EDE must also comply with the FFM data use agreement, marketplace privacy and security standards, and CMS performance standards for enrollment accuracy. For most solo brokers and smaller agencies, the quoting layer without EDE is the practical path. For more context on when EDE is worth pursuing, read the breakdown on EDE certification for solo agents.
When does it make more sense to build a custom ACA platform than to use QuoteTurbo?
Custom ACA builds make sense when the use case does not fit a general-purpose quoting tool. ICHRA administrators need employer contribution calculations that a broker quoting tool does not surface. Call centers processing hundreds of enrollments per day need custom intake flows, compliance logging, and CRM integration that a standard tool will not support. Insurtechs building embedded insurance products need their own UI and enrollment path. Agencies past 50 agents with strong brand requirements sometimes want their own platform. For general ACA broker quoting at any scale, QuoteTurbo is free and covers the quoting layer. The custom build question is about what a general tool cannot do for the specific use case.
