How vendors get data from bswift: API access or file feeds

Last verified: 2026-10-23

Key takeaways

• bswift has no public developer portal, API reference or self-service credential signup, so access is arranged per connection.
• For one employer, access starts with that employer's bswift client-services team or broker; for a reusable integration, it starts with bswift's partnership contact form.
• Demographics start in the HR or payroll system, while enrollment, life events and election changes start in bswift.
• bswift's partner pages describe API for UKG Pro, BambooHR and Workday and SFTP for Rippling, ProLiant and HiBob, with files for ADP, Paylocity and Paycor, and some pages titled "Integration (API)" describe SFTP.
• bswift describes carrier feeds as standardized EDI, which does not confirm an 834, and its EOI APIs are carrier-specific: MetLife's two new LIMRA APIs and Unum's existing EOI Decision API.
• The written request should fix direction, transport, fields, cadence and full versus change file before anyone builds.

You will not find a public bswift developer portal or a page that issues keys. bswift's public materials include no API reference and no self-service credential signup, though its own writing on API work suggests partner-only materials exist. That is the smaller surprise.

The larger one is that "the bswift API" covers several mechanisms. bswift runs API connections, scheduled file feeds and carrier EDI. A demographic change starts in the HRIS, an election starts in bswift, a deduction ends in payroll, and an enrollment ends at a carrier.

Access is arranged, not issued. For one employer, start with that employer's bswift client-services team or broker. For a reusable integration across customers, use bswift's partnership contact form.

Which way does your data move, and does bswift own it?

Each kind of data has its own origin, and only some of it starts in bswift. Every bswift HRIS and payroll partner page uses the same split: hires and terminations, name, address and contact details, pay, hours, job and location are changed in the HR or payroll system. Enrollment, life events and election changes are made in bswift.

Take a 40-person company where an employee marries in June. Her new surname and address change in the HRIS. Her added spouse coverage is a life event entered in bswift. Same employee, same week, two systems of record.

Sorted by where the data starts and where it goes:

• Demographics start in the HR or payroll system and flow into bswift.
• Enrollment, life events and election changes start in bswift.
• Deductions go from bswift to payroll, so payroll holds them too.
• Enrollment data goes from bswift out to carriers.

If you need demographics, bswift holds a downstream copy and the source is the HRIS. Taking them from the HRIS beats working from a census file or a downstream copy.

bswift's April 2026 article on its API work describes coverage today for demographics and employment, with plan, rate and enrollment coverage being added. Which transport a given customer actually gets depends on the HR or payroll system on the other end.

What carries each flow, system by system

Transport is set by the connected system, not by bswift alone. The table consolidates bswift's partner pages, one row per system, with cadence as bswift states it. "Not stated" means the page gives no such detail. The trade-offs between file and API transport are covered in SFTP versus API.

The Rippling and ProLiant pages contradict themselves on cadence. Their key points say both directions sync daily, while their summaries say changes come in "typically weekly" and deductions go back before each payroll run. Quote both to your customer and write the cadence you need into the request.

Titles don't settle transport either. The Rippling, ProLiant and Paycor pages are titled "Integration (API)", and the Rippling and ProLiant bodies describe SFTP file transfer while Paycor's describes daily files. Read the body, not the title. ADP is a different trap: one integration, two mechanisms, because ADP Marketplace doesn't provide demographics and bswift needs a separate feed.

bswift's counts don't settle it either. Its homepage states 550+ pre-built and partner integrations, while its Connectivity Hub states 450+ active file feeds, 300+ pre-built and API integrations, and 150+ API and SSO connections. Neither number tells you what runs for your customer's HRIS, which is what the table is for.

How carrier feeds and EOI decisions move

bswift's Connectivity Hub describes 450+ carrier connections "backed by standardized EDI and SSO", and its directory filters vendors by API, EDI or SSO. "Standardized EDI" names a category, so it does not confirm an X12 834 you could receive.

The 834 has a specific job. HIPAA adopted the ASC X12 834, version 005010X220, for the enrollment and disenrollment transaction: enrollment information sent from the coverage sponsor to a health plan to establish or terminate coverage. It is defined in 45 CFR Part 162, Subpart O, and has been the sole required version since 1 January 2012. An 834 is the right artifact if your product acts as or for a health plan. For anyone else, a file bswift sends to a carrier is not automatically a file bswift will send you, so "which EDI format and version" becomes a line in your request. File layout is covered in our 834 guide.

EOI runs the other way. Insurers decide, and the decision has to reach the benefits platform. bswift's April 2026 product update lists the MetLife Application API and MetLife EOI Decision API, both built on LIMRA standards, as available, with migration required as MetLife retires its older connections. The same update says Unum's existing EOI Decision API now uses LIMRA standards. Each is tied to one carrier's workflow.

The industry standard for this exchange is LIMRA's LDEx Evidence of Insurability Status & Decision (EOIS) Standard, v1.1. It lets carriers pass an employee's application status and final underwriting decision to benefits administration platforms. The payload is a status and a decision, from carrier to platform, which is why these APIs are narrow flows. LIMRA extended LDEx to enrollment in all employee benefit plans in January 2022. If you need EOI outcomes, ask for the specific carrier flow by name.

What to put in the access request

Plan on no sandbox you can sign up for. bswift's April 2026 article says it is improving OpenAPI specs, tooling, sandbox environments, sample payloads and webhook subscriptions. It describes that work as ongoing and gives no sandbox URL, credentials or signup path. A test environment is something you ask for.

Whichever route you take, the written interface request should fix ten things before anyone builds:

1. Direction: state, per field, whether data comes into bswift, goes out, or both.
2. Transport: name API, SFTP or another file transfer, and for carrier flows the EDI format and version.
3. Fields: ask for a field-level schema, and for an OpenAPI description if the flow is an API. The OpenAPI Specification 3.2 is a language-agnostic way to describe HTTP APIs so people and machines can discover what one does.
4. Population: list which employers, employees and plans are included, terminated employees among them.
5. Cadence: write down the schedule you need, since bswift's pages give both daily and typically weekly.
6. File type: choose a full file or a change file and how often. The State of Michigan's 834 companion guide defines a weekly membership change file and a quarterly audit full file for its carriers.
7. Delivery: say where output lands and how a failed delivery is flagged.
8. Authentication: name the credential type, who issues it and how it rotates.
9. Test environment: name what you can test against before production.
10. Reconciliation: agree how both sides confirm record counts and rejected records after each run.

For a single customer, send the request to the employer's client-services team or broker. For the reusable route, what an integration partnership involves is worth reading first. Partner terms, fees and timelines belong in your first message as questions.

That is one connection for one customer. The next customer's HRIS will carry a different transport and its own cadence.

When bswift is one of many systems

There are three ways to cover many employers on bswift:

• You arrange a separate connection with each employer's bswift team.
• You become a bswift partner and build one reusable integration through its partner route.
• You integrate once with a unified API that already reads bswift files.

The first spends your team's time on repetition. The second makes bswift's partner process a dependency, and its terms are not published. The third makes you depend on someone else's coverage, which you can check. No route is faster or cheaper by default.

Bindbee's API connects to 110+ HRIS, payroll, ATS and benefits systems, and bswift is one of them. Bindbee reads bswift through an SFTP export. Each employer still asks bswift for that export, so the per-employer request in section four stays. What changes is everything after the file arrives. Bindbee parses it, maps it into the same models it returns for every other system, and keeps that mapping working, so your team writes one integration instead of one per employer's file.

bswift's row in Bindbee's Model Availability Matrix covers employees, employment, compensation, dependents, company, groups and locations, plus all four benefits models: the plan catalog, each employee's enrollment, dependent coverage and per-person insured amounts.

Because the data arrives as a file, it is as fresh as the employer's last export, and the export schedule is the cadence line in your request. A delivery that stops shows up as records that stop changing, so check each record's modified_at to see when the last file landed.

Bindbee holds SOC 2 Type II and ISO 27001 and is HIPAA and GDPR compliant, with a standard BAA template and terms negotiated on enterprise plans.

The checklist in section four still scopes each connection. A direct request to bswift is a reasonable route for one employer. If your roadmap spans many HR, payroll and benefits systems, book a demo and go through bswift's row in the matrix against the fields on your list. We build the integrations. You build the product.

FAQ

What is bswift and what does it do?

bswift is a benefits administration platform employers use to hold enrollment elections, send deductions to payroll and send enrollment data to carriers. bswift states it has 300+ enterprise clients covering over 16 million employees, and it also offers ACA reporting and COBRA administration. For a vendor, the useful fact is that it originates elections, not demographics.

Does bswift have a public API?

bswift has no public developer portal, API reference or credential signup. It runs API connections with systems such as UKG Pro, BambooHR and Workday, and access for a new vendor is arranged through an employer's bswift team or bswift's partnership contact form.

Does bswift send 834 files?

bswift describes its carrier connections as standardized EDI without naming the format. If you need an 834 or another EDI file, name the format and version in your request.

How often does bswift sync with payroll?

It depends on the system. UKG Pro syncs near real time, Paylocity and Paycor exchange daily files, ADP demographics come in typically weekly, and the Rippling and ProLiant pages give both daily and typically weekly. Write the cadence you need into the request.