How to access ADP Workforce Now benefits data via API

Key takeaways

• ADP Workforce Now has no single benefits endpoint. Benefits data sits across Dependents, Beneficiaries, carrier-facing plan and enrollment APIs, spending account APIs, and Deduction Instruction.
• The Dependents and Beneficiaries APIs are the two client-side reads: each returns every record for one employee, and each needs its own scope in your application.
• The plan and enrollment APIs are built for carriers and external benefit providers, and they only return enrollments in plans that provider created.
• Deduction Instruction is the payroll side of benefits: it starts, changes, and stops general deductions, but deductions managed by ADP benefit enrollment are read-only until suspended.
• Payroll Output, which returns payroll run results, is limited to ADP Marketplace partners.

Ask ADP Workforce Now for its benefits API and you'll find several, none of which returns "benefits" as one object.

Dependents live behind one API with one scope. Beneficiaries live behind another. Plans and enrollments come through APIs ADP built for insurance carriers and benefit providers, not for the employer's own integration team. And deductions live in payroll, behind an API with its own rules about which deductions it can touch.

This page maps where each benefits object lives, who each API is built for, and what gates access, so you know which calls your integration can actually make before you design around them.

There is no single "benefits" endpoint

ADP models benefits as separate objects, each behind its own API and its own scope. Every scope has to be added to your application in ADP's Consumer Application Registry before calls succeed, and the practitioner role is the supported actor on the client-side reads.

The split that matters most is who each API serves. Two APIs are client-side reads an employer's integration can use to pull who's covered. The plan and enrollment APIs are carrier and provider rails: a carrier or external benefit provider creates plans in Workforce Now, and later receives enrollment data for those plans only. That distinction decides whether an API is even relevant to your use case.

The benefits API map

Dependents and beneficiaries are usually the first two objects an integration pulls, since most benefits use cases start by syncing who's covered and who's named on a policy.

The carrier-side rows are worth understanding even if you'll never call them. The External Benefit Enrollment payload does the job an EDI 834 file does in a traditional carrier feed: it says who is enrolled in what, effective when. The X12 005010X220 Benefit Enrollment and Maintenance transaction is the long-standing standard for that exchange; ADP's API delivers the same information as a call instead of a batch file, to carriers that have set up the integration with ADP.

What gates access

Knowing which API holds an object doesn't mean you can call it. Access depends on API Central access for the client, the right canonical scope registered for your application, and the practitioner permissions behind the calling account. Server-to-server calls authenticate with OAuth 2.0 client credentials plus an ADP-issued certificate for mutual TLS. For the auth setup end to end, see our guide to ADP Workforce Now API architecture and authentication.

Three limits are easy to miss until an integration is already built around the wrong assumption:

• Carrier and provider APIs are scoped to their own plans. A benefits platform that isn't the carrier or provider behind a plan won't see those enrollments through these APIs.
• Payroll Output is partner-only. ADP limits the API that returns payroll run results to Marketplace partners.
• Payroll Data Input writes, it doesn't read. It sends entries into a pay data batch; it isn't a way to read benefit elections or deductions back.

Page sizes also differ by API. ADP's Workers API returns 50 records per call by default, while other APIs set their own limits, so plan paging per endpoint rather than globally.

Deductions: where benefits meet payroll

Every benefits election eventually reaches payroll as a deduction, and in Workforce Now that runs through the Deduction Instruction API. Per ADP's guide, it starts, changes, and stops a worker's general deductions, each against an effective date, and supports up to nine deduction goals per employee.

Three documented details catch teams out:

• Benefit-managed deductions are read-only. Where ADP benefit enrollment manages a deduction, the API can't change it until payroll deductions are suspended for that benefit plan, either at plan level by ADP or per employee by a client practitioner.
• Status can't be toggled. The API can't set a deduction Active or Inactive; it only reads the status.
• Some goal fields are off limits. The goal Accrued and Adjustment fields aren't supported through the API.

Spending account contributions follow the same path. An HSA or FSA election still has to land in payroll as a per-cycle deduction, which is the same reconciliation work behind ordinary payroll deductions. For the full write-side decision, see our guide to writing deductions and earnings to ADP Workforce Now.

Do you call ADP directly, or abstract it?

Everything above is manageable for one API. It gets harder when a benefits integration needs several at once: separate scopes, separate actors, separate paging rules, and carrier-only APIs that don't serve your use case at all. That's true even for a team that reads every ADP guide.

Building directly gives you exact control and no dependency beyond ADP. It also means your team owns every scope request and every guide revision, for ADP and again for the next HRIS or payroll system your product needs to reach.

A unified API takes the other approach. Bindbee connects to ADP Workforce Now as one of 102+ HRIS, payroll, ATS, and benefits systems through a single API, and offers two ADP connections, per its model support reference:

• ADP Workforce Now (API): reads employees, employments, compensation, dependents, payroll runs, employee payroll runs, and payroll codes, and writes employee payroll runs with earnings and deductions by code.
• ADP Workforce Now (SFTP): reads the benefit models as well, including benefits, employer benefits, dependent benefits, and benefit coverages.

Bindbee syncs each connection every 24 hours by default, adjustable on request, and sends webhooks when a sync starts, finishes, or fails, and when a sync picks up created or updated records.

None of that removes ADP's own gates. An integration layer still calls the same scoped APIs, or the client's file feed, underneath, so the access questions above still need answering, just by whoever runs the connection. See how Bindbee connects to ADP Workforce Now.

Frequently asked questions

Is there one API to get all ADP Workforce Now benefits data?

No. ADP Workforce Now spreads benefits data across separate APIs: Dependents and Beneficiaries for client-side reads, carrier and provider APIs for plans and enrollments, and Deduction Instruction for the payroll side.

Can I read employee benefit enrollments from ADP Workforce Now?

Not as a general client read. ADP's enrollment APIs are built for carriers and external benefit providers, and return enrollments only in plans that provider created through ADP's plan APIs.

Why can't the Deduction Instruction API change a deduction?

The most common reason is that ADP benefit enrollment manages it. Those deductions are read-only through the API until payroll deductions are suspended for that benefit plan. The API also can't set a deduction Active or Inactive.

Can I get payroll results for benefits reconciliation?

Payroll run results come from ADP's Payroll Output API, which ADP limits to Marketplace partners. The Payroll Data Input API writes pay data into a batch; it doesn't return processed results.