Integration Guide for Implementing System Changes

April 16, 2026

By Max Mazzocchi (Code for America), Symonne Singleton (Center on Budget and Policy Priorities), Kira Tebbe (Aspen Institute Financial Security Program)

Background

The passage of the One Big Beautiful Bill (also known as OBBBA or H.R. 1) in July 2025 mandated significant changes to key social safety net programs, including the Supplemental Nutrition Assistance Program (SNAP) and Medicaid. To meet these requirements and minimize coverage loss, states must update the technical infrastructure that powers their program delivery. Given the aggressive implementation timeline included in the bill, states are being flooded with pitches for technical solutions promising to “fix” the problem.

To work effectively, new products must integrate well with a state’s existing systems. While some vendors claim integration will be “seamless” or “simple,” the technical reality can vary wildly. For example, a new system to collect exemptions from clients could be integrated directly into the application—or it could be a standalone portal that provides PDFs to the caseworker. Each approach has different levels of effort, risk, and impact on client experience, caseworker experience, and timeline.

For a state, not having a clear picture of whether a new system can integrate or how difficult an integration will be means that they may procure products that actually can’t integrate—or worse, trap them in an endless integration sprint that drains resources without delivering functionality. For states, a failed integration doesn’t just mean a lost investment; it means delayed compliance, depleted staff capacity, and the risk of interrupted benefits for the people who need them most.

This resource provides a roadmap for navigating these technical decisions. It defines the different levels of integration for H.R. 1 products, provides a checklist of high-stakes questions for vendors, and offers a decision framework to help states select a solution that is both feasible and sustainable.

What does “integration” mean within benefit systems?

“Integration” is overused and underdefined in benefit systems. For the purposes here, “integration” can be defined as follows:

Integration: The act of incorporating a system, product, or service into a production environment and process.

Simply put: if it’s not being used in production, it’s not integrated.

Given this definition, integration can take multiple forms, and depending on the form it takes, that integration may put more or less burden on the state.

When evaluating a product or service to implement new requirements, like those in H.R. 1, you should always ask what type of integration is being offered. Common types of integration are listed below, along with some examples. New products may have one or a combination of these methods, and vendors should be clear about which integration methods they are offering.

Integration Type	Description	Potential H.R. 1 Use Case	Pros	Cons
Standalone	The new functionality is standalone. In order to transfer data to/from another system, a caseworker must manually key it between screens.	An external portal that a caseworker uses to view volunteer or other compliance data reported by the client.	There is nothing new to build. Bugs or errors will not affect the main system. Easy to trial or pilot.	Maximum burden on caseworkers. No automation possible. Risk of data entry errors.
Browser extensions/ Robotic Processing Automation (RPA)	The new functionality sits on top of the user interface and will click buttons or fill out fields like a user.	A case checker that will pop up and alert the state case worker if a case has a high likelihood of containing an error.	Essentially zero integration cost. Caseworkers receive information directly.	No access to back end data—the new system can only access what is on the screen. May be difficult to update after installation. Can be easily broken if the user interface is modified.
File upload	The new functionality produces a file (often a CSV) that can be loaded into the eligibility system.	A batch system that provides wage records for a given batch of applicants.	Low integration cost—often much easier to implement than an API. Can be easily “turned off.”	Not real-time, can often be a slow (overnight) process. Can run into load limitations, requiring the system to periodically delay batches. Eligibility system modifications may still be needed. Caseworkers may need to perform the upload.
Application Programming Interface (API)	The new functionality exchanges data with the eligibility system automatically through a set of clearly defined rules and processes.	An API that connects data on veteran disability status with the eligibility system.	Data can be queried in real time, instead of in intervals. Demand is constant over time, rather than coming all at once. Can be easily “turned off.”	The existing system must be modified to “connect to” the new API—this incurs cost.
Embedded or custom build	The new functionality is built directly into the eligibility system.	Software code that determines community engagement compliance based on data within the eligibility system.	The eligibility system (and caseworker) has direct access to the new functionality and vice versa. New functionality will be customized to the state’s needs.	Maximum integration cost— the eligibility system must be modified and redeployed. High vendor coordination. Cannot be “turned off” without a feature flag.

Talking about integrations

When getting into the details of a particular integration, the terms listed above may not be exactly what your vendor partner is using, as terminology in this space is anything but standardized. However, there are both questions you can ask and things you can listen for to ensure you’re on the same page.

What to ask

What changes are required to my eligibility system to use this integration?
What’s the output of this product right now? What format is the output in?
Does this product work by accessing caseworker screens?
Does this product require staff to review information outside of the eligibility system?
How long will this integration take to set up?
While this product is being integrated, can it be used in a standalone way?
Can this product integrate with a legacy system? How?
Does this product rely on common APIs or standardized formats? Which ones?

What to listen for

On-demand, real-time
- These phrases all indicate that the product likely integrates via API.
XML, JSON, CSV, TSV, system-readable, machine-readable, batch, SFTP
- These terms describe data formats for system-to-system exchange; the integration is likely API or file upload.
User interface, portal, standalone experience, side car
- The system likely produces an interface for users to work with. This may mean it is not standalone, but press further for details.
Module, library
- This likely references a new piece of code that will be added to the system. This is likely an embedded or custom build.
Screen stuffing, screen scraping
- These are synonyms for RPA.

Example: Consent Based Verification (CBV)
Let’s say a vendor is providing a CBV product.

Q: What changes are required to my eligibility system to use this data?A: “We provide a set of interfaces that your system can call on-demand, and a spec that details them for developers.”Context: This is an API product.

Q: What’s the output of this product right now? What format is the output in?A: “We provide XML or JSON, and we can also provide a PDF output.”Context: The APIs produce system-readable data, but can also provide a file that could be read by caseworkers.

Q: Does this product use the user interface of my eligibility system?A: “No, we provide our own user interface for clients and caseworkers.”Context: This is not a browser extension or RPA product.

Q: How long will this integration take to set up?A: “We can have a system up within a couple weeks, and then can configure it for your system to consume.”Context: The eligibility system will need to be modified to use the new API. The timeline here will be determined by the eligibility system vendor.

Q: While a tool is being integrated into the eligibility system, is it usable in another way?A: “Yes! We provide a caseworker portal that can produce a PDF report.”Context: This tool can be used in a standalone way while it is being integrated into the eligibility system.

Q: Can this product integrate with a legacy system?A: “Yes! We can integrate with any system that can use our APIs.”Context: Not all legacy systems can use APIs. Check with your eligibility system vendor to determine if this is possible.

Q: Does this product rely on common APIs of standardized formats? Which ones?A: “Yes, we send data using standardized formats like HROpen.”Context: This is good—this provides you with flexibility in the future. If you decide to move to a different product, the format of the information won’t change, and the size of the change will be smaller.

Decision points

Each state will have its own considerations when integrating new technologies. Remembering that there is no one-size-fits-all solution, states will need to evaluate the tradeoffs and choose the approach that best supports both their immediate and long-term goals. Below are some variables to consider, and how they might help determine the best-fitting integration approach.

State system architecture

Legacy system (no APIs): A legacy state system has limitations on the integration approaches because it may not have the architecture to interact with more modern or efficient technologies like APIs. While states would benefit from modernizing their systems, this can be time consuming and not possible under tight timelines such as work requirements implementation. These systems will, instead, need to ingest data through batch processing (ideally, through an intermediate API wrapper).
Modernized system (APIs): A modernized system has more flexibility on how it ingests data and what types of systems it can integrate with. APIs are available for these modernized systems, which can allow for real-time data, faster processing, and less customization needed for technical implementation.

State staff capacity

Deep internal technical team: States with deep expertise in technical implementation have more flexibility on integration. They may be able to develop technologies in house, or be prescriptive with vendors on specific technical implementation needs.
Limited/No internal technical team: States with limited or no technical expertise will be dependent on vendors to make the detailed technical decisions for their system integration.

Vendor experience with integration in public benefits

Experience in public benefits: Vendors with integration experience, especially with public benefits programs like SNAP and Medicaid, may be better positioned for states that need a quick rollout. They may have problem-solving expertise and familiarity with similar systems. However, these vendors may also be more costly.
No experience in public benefits: Vendors that don’t have experience in public benefits may be a good fit for states that are looking to innovate, avoid vendor lock-in, or pilot changes. However, they may require more upstart time and troubleshooting in earlier stages to adapt to the specific challenges in public benefits.

User experience (client and caseworker)

Custom UX: States that want to customize UX will need to conduct research upfront to determine the user journey, needs, and experience of both caseworkers and clients. While it is an investment upfront, it will help states create solutions that are better aligned for their needs, and avoid negative impacts to clients and caseworkers.
Generic UX: Some integration solutions will have a generic UX, meaning it is the same user experience for all states, with some configuration available. The effectiveness of this approach will depend largely on the vendor experience with the given benefits program, the configuration options available, and the research conducted ahead of time.

Where will the product sit in the system?

Integrated directly into the current process: This integration approach is higher cost upfront, but should lead to a more streamlined experience in the long run. It is a better fit for states that have some internal technical knowledge.
Separate back end, shared front end: A shared front end means the user (e.g., caseworker or applicant) will have a streamlined experience, but the new functionality is separate from the state’s current system. This integration approach is a good fit for states that want to have a unified user experience, but don’t have the time or technical staff to deeply integrate on the back end.
Completely separate systems: While tempting for states with limited resources and time, completely separate systems can lead to unnecessary errors and loss in coverage due to significant administrative burden on applicants and caseworkers. For example, caseworkers may have to log in to multiple portals to access and compile information. Applicants may have to create, remember, and utilize several different logins, or remember which functionalities sit under which system. This burden is significant, and can bloat over time as the dependencies for each system become more complex to trace. If states choose this route, they should minimize the complexity of the second system, and develop a plan to modernize or improve the integration over time.

Scenarios for Applying the Decision Framework

When reasonable, states should implement industry best practices such as utilizing APIs, integrating in a modular fashion, and customizing the UX to meet specific user needs. This will reduce burden and aid in modernizing systems. However, states must adopt these best practices with the realities of tight timelines, limited budgets, and complex internal and political decision making structures. While these are by no means the only outcomes for these system characteristics, the following examples put the decision framework in context.

Scenario 1: Legacy System with Limited Technical Staff and Tight Timeline

An integration approach that starts with a batch file upload may be the best approach for a state with these characteristics. To streamline the client-facing experience, states can use a single front end, while passing the necessary files along to a separate back end. This allows for quick implementation. States may want to plan for a second phase that allows for API integration down the line.

Scenario 2: Modern System (with APIs) with Deep Technical Staff and Custom UX

A custom build, integrated directly into the current process, may be the best approach here. It allows the state to adjust the experience to meet the specific needs of applicants and caseworkers. These changes should be informed by intentional user research. While it may be more costly, both in time and finances, the modern system and technical staff means the state can make an investment upfront to have a better developed system in the long run. States will need to ensure that the scope of this integration is well defined, and that system changes can be rolled back or adjusted as new policy is implemented.

Scenario 3: Modern System (with APIs) with Limited Technical Staff and Tight Timeline

States with these characteristics may want to do an embedded integration with pre-made modules, rather than a customized user experience. This still allows for deep data integration through APIs, and may even allow for a single-door experience for applicants and caseworkers. However, there will be minimal customization, and instead states will configure their product from a selection of pre-set modules.

Moving forward

Understanding integration can be critical for states evaluating new products and services. Choosing the right integration type can be the factor that allows a state to overcome the system challenges brought by H.R. 1. Choosing the wrong integration approach can mean extreme cost, low impact, and extended timelines leading to loss of coverage for eligible people. Decision makers can apply the information from this guide to better understand how integration impacts the success of their implementation. Paired with elements of successful system design, states can ensure their response to H.R. 1 is successful, flexible, and ready for the future.