Employee Navigator API authentication: OAuth, scopes and partner access

Last verified: 2026-10-30

Key takeaways

• Employee Navigator (EN) runs its own identity server and publishes an OpenID Connect discovery document, with a token endpoint and grants that include client_credentials.
• The document lists about 70 API scopes, grouped by partner type: carrier, payroll, agency, quoting, COBRA, plan management and webhooks.
• EN does not publish how a partner gets a client ID. That step runs through an agreement with EN.
• Three different credentials get called "EN authentication": human logins, partner API clients and payroll-integration users. Only the partner client is yours to request.
• EN's Master Terms, section 3.3(h), bar automated access to EN without EN's written approval.
• Without an agreement, the other routes to EN data run through files, payroll partners or reports. Bindbee reads EN through an SFTP feed the employer or broker sets up.

Employee Navigator publishes how its API authenticates. It doesn't publish how you get in.

The discovery document reads like a developer program: a token endpoint, the server-to-server grant your engineers already know, and scopes for everything from carrier enrollment to webhooks. Then you look for a sign-up page and there isn't one. The client ID sits behind an agreement with EN.

This page is the authentication layer only: what EN's identity server publishes, what the scopes reveal about who EN builds for, which credential is which, and what to settle with EN before writing code. It's written for engineering and product leads at benefits and HR-tech platforms whose customers run benefits in EN. For every route out of EN compared side by side (payroll integrations, carrier Data Exchange, 834 feeds, reports), see Bindbee's guide to Employee Navigator data export.

How Employee Navigator's API authenticates

EN's API uses OAuth 2.0, issued by an OpenID Connect identity server at employeenavigator.com/identity. Anyone can read its configuration:

curl https://www.employeenavigator.com/identity/.well-known/openid-configuration

The discovery document, fetched on 2026-10-30, publishes:

The grant that matters for a server integration is client_credentials. Under OAuth 2.0 (RFC 6749, section 4.4), a client uses its own ID and secret to get a token, with no user signing in. That is the machine-to-machine flow a nightly sync would use. OpenID Connect adds an identity layer for confirming who an end user is. It governs EN's sign-in screens, and a back-end job never touches it.

Once EN issues you a client, the token request follows the standard shape:

curl -X POST https://www.employeenavigator.com/identity/connect/token \
  -u ":" \
  -d "grant_type=client_credentials" \
  -d "scope="

Every value in angle brackets comes from EN. The endpoint, the grant and the Basic client authentication are all in the published document. The client ID, the secret and the scopes you may request are what EN controls.

What the scopes say about who gets access

EN's scope names are grouped by the kind of partner they serve. They read like a map of EN's integration program:

Two things follow. First, the API is built around named partner categories, so ask EN which category your product falls into before you ask for access. Second, a WebhookApi scope exists. EN doesn't publicly document what it delivers, but it gives you a specific question for EN about change delivery.

The scope names are labels. EN publishes no description of what each one grants, so treat the table as a reading of names. The list also moves: API Evangelist's APIs.io profile counted 66 scopes, and the live document listed about 70 on 2026-10-30. Re-fetch it before you plan against a specific scope.

Three credentials that all get called "EN authentication"

Much of the confusion about EN access comes from three credentials sharing one name. Each governs a different actor:

The human login is for people. A server integration can't type a two-factor code, so nothing about it carries over to machine access. EN's Security page separately says its own staff get access at the minimum level their role requires. That is an internal control, unrelated to API scopes.

The payroll-integration user belongs to the payroll vendor, and each payroll guide sets its own steps. That leaves the partner API client as the one credential a software company would request for itself.

How partner access came about

EN's partner APIs grew out of carrier integrations. In 2022, EN released its Company Integration and Company Benefit Details APIs to support integrations with insurance carriers and benefit providers, with Guardian Life and Principal Financial Group named as the first integrations, according to the APIs.io profile of EN's APIs. In August 2022, EN formed an investor consortium whose stated initial focus was API architecture and standardization across carriers, payroll companies and TPAs.

Today's scope list follows the same lines, so a product outside those partner categories will need to explain to EN where it fits.

What to settle with EN before writing code

EN publishes none of the commercial or operational terms, so each item below is a question for your EN representative. Get the answers in writing before you commit engineering time:

• Eligibility for partner access, and the agreement itself
• How a client ID is issued, and which scopes your agreement grants
• Token lifetime, and whether refresh_token or offline_access applies to your client
• Fees, if any
• Sandbox access and the path to production approval
• Whether access is read-only or read and write
• Rate limits and pagination
• How changes are delivered, and whether partners can subscribe through the WebhookApi scope

Where automation needs written approval

EN's Master Terms, section 3.3(h), prohibit using any robot, spider, programmable agent, AI tool or agent, or other automated process to interact with EN's solutions or their output, unless EN expressly approves it in writing. The terms were last updated on 2026-06-09.

Scripting the EN web app with a stored HR login falls under that clause. So does an AI agent clicking through EN on a user's behalf. That makes scraping a contract question, not a technical one.

If you don't hold an EN agreement

Most platforms that need EN data never get a partner client. Their customers' data reaches them another way: through EN's payroll integrations, carrier Data Exchange or 834 files, reports, or a file feed. Bindbee's Employee Navigator data export guide compares those routes.

A unified API is a third party's API that sits in front of many source systems, connects to each one and returns the data in one normalized shape. Bindbee is one, covering 110+ HRIS, payroll, ATS and benefits systems, and Employee Navigator is among them.

Bindbee reads Employee Navigator through an SFTP feed that the employer or broker sets up. Bindbee provisions the SFTP credentials and ingests the scheduled benefits feed, so no automated process touches EN's application and no partner client ID is involved. Data is as fresh as the last file delivered, typically daily, and each record's modified_at shows when it last synced. From that feed Bindbee reads Employee, Employment, Compensation, Dependent, Company, Group and Location, plus four benefits models: the employer's plan catalog, each enrollment, dependent coverage and per-person insured amounts. All of it is read-only. Coverage per integration is listed in the Model Availability Matrix, and the connection is described on Bindbee's Employee Navigator integration page.

The questions above are the ones a buyer should ask any vendor, so here are Bindbee's documented answers:

Bindbee is SOC 2 Type II, HIPAA, GDPR and ISO 27001 compliant, with BAAs signed as standard.

A unified API isn't the right fit for every reader. Match the route to your situation:

• If you are a carrier that needs to receive enrollment, use EN's Data Exchange or 834 EDI.
• If you hold an EN partner agreement, use the partner API with the scopes it grants.
• If you serve many employer customers and need normalized benefits data, use a unified API.

EN has published the mechanics of its authentication. The agreement is the part it keeps behind the door. If you'd rather start with the data than with the agreement, book a walkthrough of Bindbee's Employee Navigator connection.

FAQ

Does Employee Navigator support OAuth client credentials?

Yes. EN's OpenID discovery document lists client_credentials among its supported grants, with a token endpoint at /identity/connect/token and client authentication by Basic header or form post. A client ID and secret come only through a partner agreement with EN.

How do I get an Employee Navigator API client ID?

EN doesn't publish a self-service sign-up or developer portal. Partner access is arranged with EN directly, and its scopes are organized around carriers, payroll providers, agencies, quoting, COBRA and plan management. Ask EN which partner category your product fits.

Is scraping Employee Navigator allowed?

Not without written approval. Section 3.3(h) of EN's Master Terms prohibits robots, spiders, programmable agents, AI tools or agents, and other automated processes interacting with EN's solutions unless EN expressly approves it in writing.

Can I get Employee Navigator data without a partner agreement?

Yes, through routes that don't need a partner client: EN's payroll integrations, carrier Data Exchange and 834 files, reports run by an HR user, or a file feed into a unified API. Bindbee, for example, reads EN through an SFTP feed the employer or broker sets up. The data export guide compares each route.