ADP API Central for ADP Workforce Now: pricing, access, and provisioning

Key takeaways

• API Central is a paid add-on the ADP client purchases; a third-party integrator still needs the client to buy access before building.
• On ADP's US listing, pricing runs from $2.50 down to $1.00 per employee per month, dropping across four bands as headcount grows, and is billed at the end of each cycle.
• Provisioning runs through purchase, activation, and project creation, where your Client ID and Client Secret are generated.
• ADP also requires a mutual-SSL (X.509) client certificate on every call, on top of the OAuth token.
• Access tokens last one hour; certificates last two years, and ADP gives 60 days' notice before one expires.
• Running this per customer means repeating the same certificate renewal cycle for every ADP client you connect to, which is the case for abstracting it.

ADP API Central is not a toggle your engineering team flips to reach a customer's Workforce Now data. It's a subscription the ADP client has to buy, priced per employee, before anyone writes a line of integration code.

Get the buyer wrong and you spend weeks waiting on a customer who didn't know they were supposed to purchase anything. Get the authentication model wrong and your integration passes every OAuth test and still fails, because ADP also requires a client certificate that OAuth alone doesn't cover.

ADP prices API Central per employee per month, from $2.50 down to $1.00 depending on headcount, according to ADP's US Marketplace listing as of 2026-09-23. It can be purchased online and digitally activated within minutes, but that speed hides a longer setup: a project, an OAuth client, and a mutual-SSL certificate all have to exist before your first authenticated call succeeds.

This guide covers who buys API Central and via which path, the full pricing schedule and how billing works, the exact provisioning sequence from purchase to first call, why the certificate exists and when it expires, and what it costs to keep running once you multiply this across customers.

What ADP API Central is for Workforce Now

ADP API Central is the product that puts a REST API in front of a Workforce Now instance. Without it, the only way to move data in or out of Workforce Now is a file export, a portal screen, or an integration ADP has already built for a specific partner. With it, the same data becomes reachable over HTTP, once the credentials and certificate covered later in this guide are in place. For the endpoints and objects themselves, see our detailed guide to the ADP API.

Buying API Central is what makes any of that possible. ADP clients gain API access specifically by purchasing API Central, and ADP states it can be bought online and digitally activated within minutes. That speed is real for the purchase transaction itself. It says nothing about who inside an integration project is supposed to click buy, which is the question that trips up most teams before they write any code.

Who buys it: the two access paths

The confusion that stalls most integration projects here is simple: it's easy to assume that because your team is building the integration, your team is the one buying access. API access itself is open to ADP clients, Marketplace partners, and third-party integrators alike; the difference is who has to pay for it first.

The client path. The ADP client, meaning the employer running Workforce Now, purchases API Central for their own instance. This is access gained by the client's own purchase, and it's the majority case: whoever owns the payroll data buys the right to expose it over the API.

The partner path. ADP also runs a Marketplace partner program, and integrations can be built by an ADP client's in-house team or by a third-party integrator working on their behalf. ADP doesn't build integrations itself, but partners are available to do the work. Choosing the partner path doesn't remove the purchase requirement, though: a third-party integrator still needs the client to buy API Central before there's anything to connect to.

If you're building as an ADP Marketplace partner rather than for a single client, there's one more obligation: ADP asks partners to submit their integration spec, pricing, and milestones within 30 days of getting access, to finalize the Developer's Participation Agreement.

Practically, this means:

• Your customer buys API Central if you're integrating with a single Workforce Now instance directly.
• The purchase requirement doesn't disappear on the partner path, it just shifts to whichever ADP client adopts your integration.
• Marketplace partners also owe ADP a spec, pricing, and milestones within 30 days of access to finalize their Developer's Participation Agreement.

What ADP API Central costs

ADP prices API Central per employee per month, banded by headcount so the rate drops as a client's workforce grows. As of ADP's US Marketplace listing on 2026-09-23, the schedule runs:

The subscription includes unlimited users and ticketed API support at every tier. ADP calculates and charges the cost at the end of each billing cycle rather than up front, so the invoice reflects actual headcount instead of an estimate filed at signup. Headcounts above 9,999 aren't listed; ADP quotes those directly. Prices also differ by region, so check the listing for your locale on the day you budget.

Optional consulting is available at $250 an hour, for teams that want ADP's help beyond what standard support covers. ADP's own materials don't agree on one detail here: whether using an API specialist requires HR department approval or is available without it, separate from the fee itself. Confirm the current process directly with ADP before you budget consulting hours as a fixed line item.

How to provision it, step by step

The provisioning sequence runs in three ordered steps between deciding to buy and having a project that can authenticate, and skipping the order rarely works because each step gates the next:

1. Purchase API Central: the ADP client buys the subscription for their Workforce Now instance; ADP states it can be purchased online and digitally activated within minutes.
2. Activate: ADP Marketplace grants instant activation and access as soon as the subscription goes through, so there's no separate approval queue after purchase.
3. Create a project and generate credentials: a Client ID and Client Secret are generated at project creation, and both are required before your first API call succeeds.

Once those three steps are done, you have a project that can authenticate, and API Central is already doing more than answering your calls: it can automate user provisioning for onboarding new hires, a feature some teams don't realize they've bought until someone asks for it later.

What the three steps don't yet give you is a call that succeeds. Credentials alone won't get you through ADP's front door: the next requirement is a mutual-SSL certificate, and it's the part that surprises most teams.

Authentication: OAuth credentials plus the mutual-SSL certificate

ADP secures API Central with OpenID Connect and OAuth 2.0, the same token exchange most modern APIs use. A valid access token is good for one hour, after which your integration requests a new one; the client-credentials grant doesn't issue refresh tokens. None of that is unusual, and it's the part most engineering teams already know how to build.

What catches most teams off guard is the second requirement. ADP also requires a mutual-SSL (mTLS) certificate that identifies your client to ADP, backed by a private key only you hold, which lets ADP confirm a request actually came from you rather than from anyone who intercepted a bearer token. Mutual SSL means the trust runs both directions: your client proves its identity to ADP's server, and ADP's server proves its identity back, before either side exchanges data.

The pattern is standard. RFC 8705 (IETF, February 2020) defines mutual-TLS client authentication and certificate-bound tokens for OAuth, and ADP's requirement follows the same idea: a stolen token is useless without the private key that matches your certificate.

The certificate itself is an X.509 certificate as defined in RFC 5280 (IETF, May 2008), and every X.509 certificate carries a bounded validity period by design. ADP's certificates are valid for two years, so renewal is part of running the integration, whoever built it.

ADP gives 60 days' notice before a certificate expires, which lines up with the scheduled-rotation guidance in NIST SP 800-57 Part 1 Rev. 5 (May 2020): keys and certificates are meant to run on a bounded cryptoperiod rather than live forever, and the notice window is your chance to rotate before the old one stops working.

Before your first authenticated call succeeds, you need three artifacts:

• a Client ID, generated at project creation
• a Client Secret, generated alongside it
• the mutual-SSL certificate, installed and paired with its private key

curl -X POST "https://accounts.adp.com/auth/oauth/v2/token" \
  --cert adp-client.pem --key adp-client.key \
  -u "$CLIENT_ID:$CLIENT_SECRET" \
  -d "grant_type=client_credentials"

Get all three in place and the request succeeds. Lose any one of them, especially a certificate nobody remembered was expiring, and a working integration can go down months later without a single code change to explain why.

Once you're authenticated, role, data entitlement, and your application's registered scope still decide what comes back. Our guide to ADP Workforce Now API architecture and authentication covers those checks, plus rate limits and pagination.

What it costs to keep running, and when to abstract it instead

The certificate that got you live is not a one-time cost. ADP notifies 60 days before each certificate expires, and that clock resets every renewal cycle, for as long as the integration runs. Miss the window and the failure looks like a broken integration, when the actual cause is a certificate nobody rotated.

None of this is a knock on API Central. It replaces file-based imports and exports with direct API data sharing, which is a real improvement over SFTP drops and manual reconciliation. The honest accounting is that the improvement comes with per-customer upkeep: a certificate to renew every two years and credentials to keep current, multiplied by every ADP client you connect to.

For a platform with exactly one ADP Workforce Now customer, that upkeep is a rounding error, and provisioning API Central directly is very likely the right call. There's no abstraction worth building for a connection you're only maintaining once.

Choose to provision ADP directly when:

• Workforce Now is the only payroll or HRIS system you need to connect to
• you're building once, for a single customer or a single internal use case
• your team already owns OAuth and certificate rotation for other integrations

Choose an abstraction layer when:

• ADP is one of several payroll or HRIS systems on your integration roadmap
• you'd rather not run a separate certificate-renewal clock per customer
• you need read and write access across systems, not just a reporting feed

The math changes once ADP is the fourth payroll system on your roadmap, not the first, and the same renewal cycle has to run separately for each one.

This is the case an integration layer like Bindbee is built for: it connects to 102+ systems across HRIS, payroll, ATS, and benefits, including Workforce Now, through one API, so certificate rotation and connection monitoring happen behind that layer instead of inside your own on-call rotation for every customer. Every connector, including ADP's, uses the system's own API authentication, with no screen scraping.

The abstraction also has to do more than watch for problems. Bindbee supports read and write across connected systems. Syncs run every 24 hours by default and can be adjusted per connection, and webhooks fire when a sync starts, finishes, or fails, and when a sync finds changed records, so a broken credential shows up as a sync error event instead of silent staleness. Newfront went from a 12-week HRIS integration cycle to a first sync in 48 hours, and Bindbee prices per active connection with unlimited API calls, so usage never changes what a connection costs.

Bindbee's Workforce Now coverage is checkable directly, and the per-connection pricing is public too. Neither replaces the decision this guide exists to support. If ADP is your one integration, build it directly. If it's one of several, we build the integrations, so your team builds the product instead of a certificate-rotation schedule.

Frequently asked questions

Do I (the software vendor) or my customer buy ADP API Central?

The ADP client purchases and activates API Central for their own Workforce Now instance, not the vendor building the integration. A third-party integrator or Marketplace partner still needs that client to buy access before anything can be built, and API access itself is available to clients, partners, and third-party integrators alike, so the purchase requirement doesn't disappear on any path, it just shifts to whoever employs the workforce.

How much does ADP API Central cost per employee?

Per ADP's US Marketplace listing as of 2026-09-23, pricing runs from $2.50 per employee per month for the first 999 employees down to $1.00 for 5,000-9,999, with optional consulting at $250 an hour. Costs are calculated and charged at the end of each billing cycle rather than up front.

Can API Central be activated immediately after purchase?

Yes. ADP states API Central can be purchased online and digitally activated within minutes, and ADP Marketplace grants instant access on subscription. Activation isn't the same as being ready to make calls, though: your Client ID and Client Secret still need to be generated at project creation before the first authenticated request works.

Why does ADP require a certificate as well as OAuth credentials?

ADP secures API Central with OAuth 2.0 and OpenID Connect, plus a mutual-SSL (X.509) certificate that proves each call comes from your client, the pattern RFC 8705 standardizes. The certificate is valid for two years, and ADP gives 60 days' notice before it expires.

How long is an ADP access token valid?

One hour. Request a new token before it expires; the client-credentials grant doesn't issue refresh tokens. That is separate from the mutual-SSL certificate's own two-year expiry cycle.