Reference Live

WorkAxle exposes three reference surfaces. Each is browsable in a live, interactive tool — there's no separate documentation site to fall out of sync. Pick the surface that matches your use case below.

At a glance

All three are public to browse without authentication. Executing live calls against the API still requires a valid token — see Authentication.

GraphQL — App schema

/v2/graphql is the same API that powers WorkAxle's web and mobile apps. It's optimized for interactive, user-facing workloads: small reads, real-time mutations, single-record operations.

Browse it: opens GraphiQL, a built-in IDE with a schema explorer (right pane), query editor (left), and response viewer (middle). Click any type in the docs pane to drill into its fields, arguments, and return shape.

Most commonly used domains: employee, schedule, shift, time-entry, timecard, availability, leave, work-package, group, location, manager, payroll. The full schema covers over 130 domains including hierarchy, attestation, audit, forecasting, and dozens of specialized areas — browse them all in GraphiQL.

When to pick this surface

• You're building something a person will use, even occasionally.
• You need a small focused read (one employee, one shift, one day's schedule).
• You're reacting to user input and need low-latency mutations.

GraphQL — Integration schema

/v2/integration/graphql is built for machine-to-machine traffic — partner connectors, scheduled sync jobs, bulk data flows. It exposes import/export operations, integration-kind mutations, and a different (often smaller) shape than the App schema.

Frequently used import mutations:

• importEmployees — bulk create/update employee records
• importShifts — bulk create/update shifts
• importShiftTags — bulk shift-tag taxonomy
• importLocations — bulk location/branch records
• importTimeBuckets — bulk time-bucket definitions
• importTimeoffs — bulk time-off entries
• importLeaveBalances — bulk leave-balance adjustments
• importWorkPackages — bulk work-package ingest
• importWorkPackageEvents — work-package event stream
• importClockTimeEvents — bulk clock-in/clock-out events

Most imports use the Import…Input + ImportOptionsInput shape and return a typed result with per-row success/error reporting.

When to pick this surface

• You're moving data in or out at scale (hundreds to millions of rows).
• You're a connector (HRIS, payroll, IDP, etc.) running on a schedule.
• You need the structured-error batch semantics — per-row success/failure rather than all-or-nothing.

REST (legacy)

/doc is WorkAxle's REST API. It uses JSON:API v1 and predates the GraphQL surface. New endpoints aren't added here; existing ones are migrated to GraphQL over time. Use REST when no GraphQL equivalent exists yet.

For curated, interactive endpoint documentation with live cURL builders, see the REST API page in this portal. The /doc link below is the full Slate-generated reference covering every endpoint.

When to pick this surface

• The specific endpoint you need isn't on either GraphQL schema yet.
• You're maintaining an existing REST integration and don't want to migrate it.

Migrating away from REST: for most domains a GraphQL equivalent exists today. If you're starting fresh, default to GraphQL; the REST surface is in maintenance mode.

Cross-surface conventions

Identifiers

IDs are opaque strings. Don't parse them, don't compute them, don't guess them. Always read IDs from a previous response.

Time and timezones

All timestamps are ISO 8601 with a timezone offset (e.g. 2026-05-12T14:30:00-04:00). Read carefully — ...Z (UTC) and ...-04:00 (Eastern) are different moments.

Pagination

• GraphQL uses cursor-based pagination with pageInfo { hasNextPage, endCursor }. Pass after: $endCursor to fetch the next page.
• REST uses JSON:API offset pagination — page[number] and page[size] query parameters, with links and meta.totalPages in the response.

Errors

• GraphQL — HTTP 200 with an errors array. Inspect message, path, and extensions.code.
• REST — non-2xx HTTP status with a JSON:API errors array. Each entry has status, title, and detail.
• Batch ops on the Integration schema — partial success is reported per row with structured payloads including row index, field path, and trace ID. Don't assume all-or-nothing.

Multi-tenancy

Every request is implicitly scoped to the tenant tied to your token. You cannot read or write data across tenants. There is no tenantId parameter — the server resolves it from the token.

Rate limits

The current limit is 5,000 requests per 5-minute rolling window, counted per source IP. Requests above that are rejected with 429 Too Many Requests until the window rolls off. Because the limit is per-IP and not per-user, if your integration sends traffic through a shared NAT or proxy, all of it counts against one bucket — concurrent bursts are the usual cause of hitting the limit.

Recommended approach:

1. Treat 429 as retryable — use exponential backoff with jitter, and honor the Retry-After header when present.
2. Cap concurrency and smooth bursts — run a client-side rate limiter / token bucket below our threshold rather than firing requests in parallel waves.
3. Batch where the API supports it to reduce request count.