Employee Navigator data export: every route out, and which one fits your platform

Last verified: 2026-10-23

Key takeaways

• Choose the route by destination, not by whether an API exists. Each Employee Navigator route is built for one kind of recipient: a payroll provider, a carrier or a health plan.
• The 834 feed is the HIPAA transaction for sending enrollment to a health plan, and Employee Navigator prices it at $0.45 per enrolled employee per month, paid by the agency.
• Reports are the route an account user can reach today, and whether they can be scheduled is unconfirmed.
• Employee Navigator's published APIs, released in 2022, serve carrier and benefit-provider integrations, and its OAuth scopes are public while its credentials are not.
• Its Master Terms bar automated access, AI agents included, without written approval.
• For recurring, full-record access across many employers, the realistic routes are an arrangement with Employee Navigator or a provider that already reads its files.

Employee Navigator data leaves through purpose-built routes: payroll integrations, carrier Data Exchange files, 834 EDI feeds, reports, partner-built files, and approved partner or API integrations. Each one is aimed at a particular destination, so pick by destination and cadence.

That is why "does Employee Navigator have an API?" is a weak starting question. Payroll gets a fixed field set, carriers get a multi-tenant enrollment file, health plans get an 834, and a platform that wants recurring, full-record access gets a conversation.

Every route out of Employee Navigator, side by side

Every route except reports is aimed at a specific kind of recipient. The table sorts them by what decides a build. Figures come from Employee Navigator's integrations guide (December 2025) unless the cell names another source. For how file and API routes fail differently, see SFTP versus API.

Take an ICHRA platform that needs each employee's coverage status and dependents to size reimbursements. The payroll route looks cheapest, and it does move demographics. But it exists to keep payroll in step with Employee Navigator, so it hands this platform names and addresses, without enrollments.

The 834 looks like a generic export because it is a standard EDI file. Federal rule gives it one direction. The enrollment and disenrollment transaction is the transmission of subscriber enrollment information to a health plan, and 45 CFR §§162.1501 and 162.1502 adopt the ASC X12 834 as its standard. Employee Navigator prices the feed at $0.45 per enrolled employee per month, based on the highest eligible feed per group, and the agency pays. File layout is covered in Bindbee's 834 explainer.

Carrier-side data has its own industry standard. LIMRA's LDEx standards cover the data exchanged between insurance carriers and benefits-administration platforms. Employee Navigator's published material doesn't say whether its Data Exchange files conform to LDEx, so ask before you assume it.

A route built for one recipient can still reach a platform when the broker or employer configures delivery to it. That is what the last row describes. It leaves reports as the one route with no recipient built in.

Reports: the route you can use today

Reports are the one route an account user can reach without a partner agreement, and they suit one-time, migration, analysis and pilot work. Whether they can be scheduled is unconfirmed, so don't design a recurring pull around them yet.

Neither Employee Navigator's product pages nor its training material list report fields or file formats, so treat both as unknown until you are holding a sample.

The scheduling question has a misleading answer in circulation. The phrase "Reports are available on-demand and may also be scheduled" appears in search results, but it comes from Associated Bank's HRA marketplace listing, where it describes that partner's HRA reporting. Confirm scheduling with the account admin or broker before you build.

Reports fit when the need is:

• a one-time load of existing employees and enrollments
• a migration of a client onto your platform
• analysis of a client's enrollment before you commit to a build
• a pilot with a single employer

Each of those ends. Once the data needs to refresh itself every cycle, a report someone has to run becomes a chore, and the next thought is the API. For a one-time load, the trade-offs are close to a census file's.

Is there an Employee Navigator API a third-party platform can use?

Employee Navigator's published APIs were built for carrier and benefit-provider integrations, so a third-party platform should plan on a negotiated arrangement with Employee Navigator.

Employee Navigator announced the release on 14 March 2022. The Company Integration and Company Benefit Details APIs support integrations with insurance carriers and benefit providers, followed more than two years of work with insurers, and cover medical, dental, vision and supplemental benefits. Guardian Life, Principal and an undisclosed carrier were the first integrations, rolling out over the following months. "Partner access" here means a carrier.

The confusion starts with the scopes. Employee Navigator publishes its OpenID discovery document, which lists 66 API scopes, authorization endpoints under /identity/connect, and flows including authorization code and client credentials. Third-party catalogs such as apis.io repeat it. That reads like a developer program, but a discovery document describes how sign-in works, and nothing on it says who may obtain a client ID. There is no public developer portal. Employee Navigator's integrations guide lists sales@employeenavigator.com for Data Exchange inquiries, which is the nearest published contact.

Browser automation is ruled out by contract. Employee Navigator's Master Terms (updated June 2026) bar robots, spiders, AI tools or agents and other automated access without written approval, and bar using the platform to build competing data exchange tools. Get approval in writing before automating anything.

What to settle before you ask

Standing comes first. ProLiant's August 2026 announcement says broker-owned accounts remain broker-led under its licensing model. A platform rarely owns the account, so the request usually travels through the broker or employer who does.

A request that gets built names five things:

• People: employees, and dependents if you need them
• Benefits: plans, enrollments and coverage
• History: how far back the data has to reach
• Operations: how many employers, and how often the data must refresh
• Authorization: your role, and the account owner's sign-off

Authorization is the line most requests leave vague. HHS's Privacy Rule, 45 CFR §164.504(f)(1)(iii), lets a group health plan, or its issuer or HMO, tell the plan sponsor (the employer) who participates or is enrolled, without the plan-document amendment the rest of that section requires. That exception covers the employer. A platform receiving the data on the employer's behalf needs its own basis, usually a business associate agreement or a services agreement with the employer. Have counsel name it.

Before anyone builds, ask for a small, authorized sample export. Test three things in it: that the employee identifier is stable, that dependents link to the right employee, and that dates survive. For our ICHRA platform, that last one means a mid-year dependent addition shows its effective date.

Choosing a route by destination

Match the route to where the data is going, then check the one thing that would break it.

If your destination is payroll, a carrier or a health plan, use the native route in the first table. A unified API doesn't replace them. The last row is where the real choice sits.

Choose an arrangement with Employee Navigator when:

• Employee Navigator is the only benefits-admin system your clients use
• you can wait on a negotiated scope, because Employee Navigator decides what it exposes
• the account owners will sponsor the request

Choose a unified API when:

• your clients run benefits in several admin systems and you want one integration
• you would rather not negotiate access system by system
• you want coverage you can check per integration before committing

When the need is recurring access across employers

Employee Navigator's own path for recurring, multi-employer access is an arrangement, and arrangements are per system. A unified API moves that integration work to someone who already does it.

Bindbee's API connects to 110+ HRIS, payroll, ATS and benefits systems, and it reaches Employee Navigator through SFTP: the employer or broker configures Employee Navigator to deliver the benefits feed to Bindbee, and Bindbee normalizes each file into the same models it returns for every other system. Employee Navigator'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 last export. A delivery that stops shows up as records that stop changing, so check each record's modified_at. Webhooks notify on link, sync, failure and relink, and when a sync creates or updates records, and records can be returned with the full upstream payload as raw_data, so a field Bindbee doesn't model is still there.

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 decision the whole page turns on is destination. Every native route is right for the recipient it was built for, and if your destination is your own product, the question moves from which export to who holds the integration. If Employee Navigator is the system your clients share, see how Bindbee connects to it.

FAQ

Does Employee Navigator have an API?

Yes, for carriers and benefit providers. Its Company Integration and Company Benefit Details APIs, released in 2022, serve insurer integrations. There is no public developer portal for other platforms; access is arranged with Employee Navigator.

How much does an Employee Navigator 834 feed cost?

Employee Navigator's integrations guide prices the 834 feed at $0.45 per enrolled employee per month, based on the highest eligible feed per group. The agency pays, and the feed requires the Enhanced Plus license or higher.

Can Employee Navigator reports be scheduled?

Employee Navigator's own documentation doesn't say. The "may also be scheduled" line found in search results comes from a marketplace partner's HRA listing. Ask the account admin or broker.

Does Employee Navigator integrate with ADP?

Yes. The Employee Navigator connector for ADP Workforce Now exchanges name, date of birth, address, gender and phone both ways, sends deductions to ADP, and brings SSN, payroll ID, hire and termination dates and compensation from ADP.