Skip to main content
Toku connects to ADP Workforce Now using ADP’s OAuth 2.0 client credentials flow combined with mutual TLS. Every call — token requests and API requests alike — is authenticated with both a client ID/secret and an ADP-issued X.509 client certificate.

OAuth 2.0 + Mutual TLS Flow

1

Issue credentials

Your ADP administrator creates a dedicated API project for Toku in ADP API Central, which issues the client ID, client secret, and X.509 client certificate and key. (For ADP Marketplace subscriptions, credentials are granted through the Consent Manager instead.)
2

Request a token

Toku’s backend presents the certificate and client credentials to ADP’s token endpoint and receives a bearer access token.
3

Refresh

Tokens expire after 60 minutes. Toku requests a fresh token automatically before expiry — the connection stays live without manual intervention.
A successful response:
Authenticated API requests carry the bearer token and the same client certificate:

Mutual TLS Requirements

Because ADP validates the certificate on every request, a leaked client secret alone cannot access your data — the certificate is required as a second, independent factor.

Environments

Credentials and certificates are generated in your own ADP API Central project, so your ADP admin controls (and can revoke) Toku’s access at any time. See ADP’s developer documentation and the mutual TLS guide to validate any of the calls referenced in this section.

Next

Employee Sync

How Toku reads your worker roster

Payroll Sync

How Toku tracks pay cycles and payroll output