Which Workday Integrations Count Against Your API Entitlement?

The single most common question we hear from Workday customers about Flex Credits: "Do my integrations count?" The answer depends on what type of integration, who built it, and whether it's been modified.

This guide classifies every major Workday integration technology against the Platform Entitlement policy. We use three categories: Counted (production calls consume entitlement), Exempt (excluded from entitlement metering), and Conditional (depends on specifics).

The policy rule that matters

The Flex Credits and Platform Entitlement Policy defines an API Request as a request for data transfer to the connection point between a Workday application and either a custom-built integration or an external application. Unless Workday specifies otherwise, production API requests count against the customer entitlement.

The exemptions are specific. Here's the full list from the current policy:

Does NOT count against entitlement:

• Workday's own AI agents (as described on the Rate Card)
• Applications built by Workday Partners (Built on Workday)
• Workday Core Connectors (unless augmented by Studio integrations)
• Custom integrations with Workday Acquisitions (e.g., HiredScore)
• Workday Everywhere (Slack, Microsoft Teams integrations)
• Third-party time clocks using specified Workday web services
• 5XX server errors

DOES count against entitlement:

• External applications accessing Workday APIs
• Third-party (external) AI agents
• Customer-built Extend applications
• All integrations not built by Workday (including Certified Partner integrations and EIBs)

Everything not on the exempt list is in scope unless proven otherwise.

The metering matrix

Counted - High confidence

SOAP / Workday Web Services. SOAP is explicitly listed as a Workday API transport. Production calls from custom or external integrations count against your entitlement. This includes Get, Put, and Submit operations.

REST API. REST is explicitly listed alongside SOAP as Workday API traffic. GET, POST, PUT, PATCH, and DELETE operations from non-exempt integrations all count.

RaaS (Reports as a Service). Workday expressly classifies RaaS as an API and tracks API activity across transports. External report requests should be modeled as API requests.

Custom middleware extraction. Any external system continuously pulling data from Workday through REST, SOAP, or RaaS counts. This includes iPaaS platforms (Dell Boomi, MuleSoft, Workato), data warehouse loaders, and custom scripts.

Third-party agents using normal APIs. An external AI agent calling Workday REST or SOAP directly - Claude via a custom MCP server, Copilot via a connector, or any vendor tool hitting Workday APIs - counts against the API entitlement like any custom integration.

Exempt - Medium-High confidence

Unmodified Core Connectors. The policy explicitly exempts Workday pre-built, unmodified integrations including Core Connectors. This covers standard payroll connectors, benefits carrier feeds, and other Workday-delivered integrations - as long as they haven't been modified.

Built on Workday applications. Applications that have earned the Built on Workday certification receive an explicit API entitlement exemption. This is a specific certification status, not a generic label.

Workday Everywhere. Explicitly exempted in the policy - this covers Slack and Microsoft Teams integrations.

5XX server errors. If Workday returns a 5XX error, that failed call does not count against your entitlement.

Third-party time clocks. Time clocks using specified Workday web services are excluded - a narrow but useful carve-out for organizations with frontline workers.

Workday-built agent API calls. The underlying API traffic generated by Workday's own agents (Self-Service Agent, Payroll Agent, etc.) is reportedly excluded from the API entitlement meter. The agents themselves consume Flex Credits through their own rate-card meter.

Conditional - requires investigation

Modified Core Connectors. The moment you modify a Workday-delivered connector, it may lose its exemption. The policy reportedly distinguishes between modified and unmodified Workday integrations. If you've customized a Core Connector, treat its API traffic as potentially countable until you confirm otherwise with Workday.

WQL (Workday Query Language). WQL has a REST/API endpoint and appears as an API type in the WCP Gateway documentation. It's likely counted when invoked by external applications, but the policy doesn't call it out by name. Confidence: Medium-High.

Graph API. Graph is a Workday API type routed through the WCP Gateway. Same situation as WQL - likely counted for external/custom integrations, but not separately named in the policy.

EIB (Enterprise Interface Builder) - inbound. An inbound EIB can load data through Workday Web Services. But one EIB run is not automatically one API request. The underlying WWS calls it generates may count, but the integration event itself is not clearly a standalone billing unit under the current policy. Do not assume 1 EIB event = 1 API request.

EIB - outbound. An outbound EIB generates a file, often from a custom report or web service data source. The file delivery itself (SFTP push) is not proven to be an API request. But if the EIB retrieves data through RaaS or WWS in its data-source phase, those underlying calls may count.

Studio integrations. Studio can make HTTP, WWS, and RaaS requests. The API traffic generated by custom Studio flows should be assumed countable unless a specific exemption applies. Custom integrations are not listed among the policy exemptions.

Orchestrate. WCP API Gateway serves Orchestrate traffic. No blanket Orchestrate exemption was found in the policy. Workday API calls made by orchestrations should be modeled as countable.

Extend applications. This is the biggest trap. Extend does not automatically equal Built on Workday, which does not automatically equal API exemption. The entitlement schedule provides a +50% uplift for customers licensing Extend, but that's an increase to the entitlement budget, not an exemption from metering. Customer-developed Extend apps should not be assumed exempt.

Workday Marketplace applications. No blanket exemption was found for Marketplace-listed applications. A Marketplace listing is a distribution channel, not a billing classification. Only applications that have earned the Built on Workday certification receive the explicit exemption.

Separate meter - not counted against API entitlement

Workday Agent-Ready MCP Tools. These have their own Flex Credit meter: 10 to 50 credits per 100 tool calls depending on agent type. They don't consume API entitlement - they consume credits directly. This is the metering path for external agents using Workday's official agent interface rather than calling REST/SOAP directly.

Custom Extend agents. Workday Extend Professional custom agents consume 1 to 3 credits per invocation plus 5 to 25 credits per 100 Agent-Ready Tool calls. Separate meter from API entitlement.

The key distinctions

Billing unit ≠ integration unit. An EIB run, a Studio integration event, a business transaction, a record, and an API request are all different things. Never equate them without PCC evidence.

Direction doesn't matter by itself. The rate card says standard API calls include ingress and egress. Inbound writes and outbound reads are both API requests.

The initiator matters. The same Workday API call can be exempt or countable depending on who initiated it. A Core Connector making a SOAP call is exempt. Your custom middleware making the same SOAP call is not.

Policy version matters. The policy version incorporated into your specific agreement governs what's billable. A public Workday announcement or current rate card doesn't automatically amend an older MSA.

What to do with this information

Pull your integration inventory. For each integration, classify it against this matrix. Cross-reference with your PCC API Activity Reports to see actual volumes. Focus optimization on the highest-volume countable integrations.

For anything in the "Conditional" category, get written confirmation from your Workday account team before assuming it's exempt or counted. The cost of being wrong in either direction is real - either unexpected credit consumption or unnecessary optimization work.

Frequently asked questions

If I modify a Core Connector, does all its traffic become countable? The policy reportedly removes modified Workday integrations from the exemption. The safest assumption is yes - modification removes the exemption. Confirm with your Workday account team.

Are sandbox/non-production API calls counted? The policy focuses on production API requests. Non-production traffic is tracked but not typically charged.

Does pagination count as separate API requests? Each paginated request is technically a separate API call. If you're retrieving 10,000 records at 100 per page, that's 100 API requests. Increasing page size (Workday allows up to 999 in many APIs) reduces the call count.

What about retries? A retry is another API request. An integration with a 10% retry rate adds 10% to its API consumption. Designing for exponential backoff instead of immediate retry reduces both consumption and system load.

Classify your integration portfolio with our Flex Credits Calculator, or request a Consumption Baseline Assessment.