UKG API Documentation: Pro, Pro WFM, and Ready Compared

Key takeaways

• “UKG” is not one API: three separate families, Pro (HCM), Pro Workforce Management (formerly Dimensions), and Ready, each ship their own data model, host, and auth setup.
• The host is the tell: an ultipro.com address points to Pro, a mykronos.com address to Pro WFM, and a saashr.com address to Ready.
• Pro and Pro WFM share the UKG Developer Hub but not a data model: Pro covers HR, payroll, benefits, and talent, and Pro WFM covers scheduling, time, and attendance.
• UKG Ready's REST reference is public and hosted on the Ready platform itself, but every call needs an OAuth application set up inside the customer's tenant.
• UKG Pro runs two generations of auth side by side: Basic auth with a web service account for core HCM APIs, and OAuth 2.0 client credentials from the Developer Console.
• Supporting UKG broadly means maintaining three data models and three version lifecycles, which is where an abstraction layer starts to look cheaper than three parallel builds.

A customer tells you they run UKG. That sounds like a single fact to plan an integration around. It's actually three: UKG sells Pro, Pro Workforce Management, and Ready as separate products, each with its own data model, its own login host, and its own documentation. Build against the wrong one and you've mapped the wrong fields, authenticated against the wrong flow, and read documentation for a product your customer doesn't use.

UKG Pro Workforce Management is the current name for what UKG sold as Dimensions; UKG made the change to bring it under the UKG Pro suite. It runs on a customer-specific mykronos.com host. UKG Pro, formerly UltiPro, runs on ultipro.com hosts that vary by customer data center. UKG Ready sits on its own platform on saashr.com. None of the three assume the other two exist.

This page separates the three: what each one covers, how to tell which one your customer runs, and what it costs to support all three instead of one.

The three UKG API families (and how to tell which one is yours)

UKG Pro is the HCM system, documented on the UKG Developer Hub as the Pro HCM API Specifications. UKG Pro Workforce Management is the workforce management system, covering scheduling, time, and attendance. UKG Ready is a separate platform aimed at smaller employers, and its REST reference lives on the Ready platform rather than alongside the other two.

The fastest way to identify which one a given customer runs is the host in their browser bar:

• UKG Pro runs on an ultipro.com host and covers HR, payroll, benefits, and talent records.
• UKG Pro Workforce Management runs on a customer-specific mykronos.com host and covers scheduling, time, and attendance data.
• UKG Ready runs on a saashr.com host, on its own platform built for smaller and midsize employers.

Knowing which family answers the phone doesn't tell you what it does once you've authenticated. That comparison is the one nobody assembles in one place.

Side-by-side: data domains, hosts, auth, and doc entry points

Once you know which family you're facing, four things set the scope of the build, per UKG's own documentation: what data it covers, where it lives, how you authenticate, and where the documentation starts.

The auth column is where most first builds go wrong. For Pro, UKG's Developer Hub says HCM APIs using Basic authentication are only accessible with a web service account, which a system administrator creates under Service Account Administration. Its newer path issues OAuth tokens with the client_credentials grant and a global-tenant-id header, set up from the Developer Console. Our guide to UKG Pro API authentication walks through both. Credentials don't cross families: a client set up for Pro doesn't authenticate against Pro WFM or a Ready tenant.

Two of these three families, Pro and Pro WFM, even share a front door. They don't share much else.

Pro WFM and Pro HCM: the two Developer Hub families

UKG Pro and UKG Pro Workforce Management both live on the UKG Developer Hub and still describe two different systems with two different data models.

UKG Pro (HCM)

UKG Pro is what developer.ukg.com labels the API Specifications, the REST reference for HR, payroll, benefits enrollment, and talent records. UKG renamed UltiPro to UKG Pro, so if a customer mentions UltiPro, they're on Pro, full stop. The credential model is the part to get right early; our explainer on the UKG Pro web service account and Customer API Key covers which key goes where.

UKG Pro WFM (formerly Dimensions)

UKG Pro Workforce Management is the current name for what UKG sold as Dimensions, and it covers the operational side: scheduling, time, and attendance data that Pro's HCM side doesn't touch. UKG's WFM authentication doc shows an OAuth password grant, where a runtime user's username and password are sent with a client ID and secret. Tenants set up for UKG Authentication can also create client credentials under Client Management, and UKG recommends one set per application. For the deeper mechanics of working with UKG's APIs day to day, see Bindbee's guide to the UKG API.

Two families, one portal, and little in common beyond the portal. UKG Ready doesn't share even that.

UKG Ready: the separate platform

UKG Ready runs on UKG's saashr.com platform, aimed at smaller and midsize employers. Its REST reference is published at secure.saashr.com/ta/docs/rest/public, hosted on the Ready platform itself rather than alongside Pro and Pro WFM.

The reference is public, so you can read Ready's endpoints and webhook catalog before a customer relationship exists. What you can't do from outside is call anything: every request needs a bearer token, and Ready's docs say both supported OAuth flows require an OAuth application configured inside the customer's tenant first. Plan on getting that access through the customer. Our guide to UKG Ready API architecture and authentication covers the setup step by step.

UKG Ready is a separate integration target from Pro and Pro WFM, not a thinner version of either.

That's the identification and the shape of all three. What's less obvious is that the shape keeps changing underneath you.

Three version clocks, not one

Each UKG family versions and retires its APIs on its own schedule, documented in its own place.

Ready is the most explicit. Its REST reference says a new version is created when a breaking change is needed, and the whole resource is versioned, not just the endpoint that changed. The old version is deprecated, and every request to it returns a Deprecated header with an expiration date and a link to the docs. Because resources move to new versions only as they change, a single Ready integration can end up calling several API versions at once.

Pro and Pro WFM announce changes through the Developer Hub. UKG's other products keep their own clocks too: UKG HR Service Delivery, for example, deprecated its API v1 in April 2024 and retired it on 1 October 2025.

So a migration on one family says nothing about where the other two stand. If you're inheriting an existing UKG integration, check which version each family is actually calling before you touch anything else, and on Ready, log any Deprecated header your client receives.

Three data models, three hosts, three auth setups, three version clocks. That's the bill for the word “UKG,” and nobody adds it up until they're the one paying it.

Three APIs or one interface: the honest build decision

Everything above is a cost you pay once if you support exactly one UKG family, and three times if you support all of them. One data model, one auth flow, one host, one version schedule: that's a normal integration. Three of each, in parallel, indefinitely, is a different kind of commitment.

If your product only ever touches one UKG product, for one segment of customers, this is close to moot: build against that API directly, bookmark its deprecation page, and move on. The decision gets real once “we support UKG” starts meaning customers on two or three families at once.

Build direct when:

• You support exactly one UKG family across your customer base.
• The integration is a one-off for a single large customer, not a repeatable product feature.
• Your team has capacity to own an auth flow, a data model, and a deprecation calendar per family you add.

Weigh an abstraction layer when:

• You're on, or heading toward, two or more UKG families at once.
• UKG is one of several HRIS, payroll, or benefits systems you already connect to.
• Three separate version schedules is more ongoing maintenance than your team wants to own.

An abstraction layer's job is to sit in front of that multiplication and expose one interface behind it, regardless of which UKG family, or which other HRIS, is on the other side. See what a unified API actually does for the general mechanics.

Bindbee is one example: it connects to UKG Pro, UKG Pro Workforce Management, UKG Ready, and 102+ HRIS, payroll, ATS, and benefits systems in total through one interface. Each customer authorizes the connection with whatever that system supports: OAuth, an API key or token, or a certificate. 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.

If UKG is one of several systems you're being asked to support, see how Bindbee covers UKG and the rest through one API: we build the integrations, you build the product.

FAQ

Was UKG Dimensions renamed?

Yes. UKG Pro Workforce Management is the current name for what UKG sold as Dimensions, and the two terms refer to the same workforce management platform.

Does UKG Ready use the same API as UKG Pro?

No. UKG Ready runs on the saashr.com platform with its own REST API, documented at secure.saashr.com/ta/docs/rest/public, separate from the Pro HCM and Pro WFM families on the UKG Developer Hub.

How do I tell which UKG product a customer is on?

The host is the tell. UKG Pro runs on an ultipro.com host, UKG Pro Workforce Management on a customer-specific mykronos.com host, and UKG Ready on saashr.com.

How does UKG Pro API authentication work?

UKG Pro runs two models side by side. HCM APIs using Basic authentication require a web service account created by a system administrator. The newer path uses OAuth 2.0 client credentials from the Developer Console, with the organization ID sent in a global-tenant-id header.