Reference · built on requestConnectorHR, scheduling & workforce

Quinyx

Organization groups, employees, shifts, absences, forecasts, and leave applications from Quinyx.

Request accessPricing ↗

About

Quinyx is a cloud workforce management system for scheduling, time and attendance, absence, and demand forecasting, sold to retail, hospitality, logistics, and healthcare employers. Its developer portal documents API v3, marked recommended for new integrations, alongside API v2 and a separate User API for an employee's own shifts and leave applications. Production and Release Candidate environments each have EU and North America base URLs.

Through Fibric, an operator lists a group's shifts and employees from v3, reads absences and calculated forecasts from v2, and proposes an absence entry or a forecast correction. You approve it, the change is applied once, and a receipt records what changed and why.

This is a reference listing. It documents what Fibric would read from Quinyx and what it could propose, based on the vendor's published interfaces. Fibric builds it under a managed deployment when you request it; selecting it here installs nothing.

Inputs

  • Organization groups and roles through GET /organization/v3/groups and the v3 Role and Role Assignment resources
  • Employees with badgeNumber, homeGroupId, and managerId through GET /hr/v3/employees, scope hr:employees:read
  • Shifts by group, employee, begin range, and status through GET /schedule/v3/shifts, scope schedule:shifts:read
  • Absence schedules and the absence types allowed for an employee through the v2 absence-schedule and absence-types endpoints
  • Calculated forecast values per forecast variable and unit through GET /v2/forecasts/forecast-variables/{externalForecastVariableId}/calculated-forecast
  • Optimal headcounts, labor standards, opening hours, and forecast events through the v2 forecast resources
  • An employee's own shifts and leave applications through the User API, when acting for that employee

Proposed actions

  • Target capability: propose a full-time or part-time absence for an employee at a unit through POST /v2/schedule/groups/{groupId}/absences
  • Target capability: propose removing an absence through DELETE /v2/schedule/groups/{groupId}/absences/{absenceId}
  • Target capability: propose actual, budget, or forecast data uploads and an edited calculated forecast through the v2 forecast-data endpoints
  • Target capability: propose an employee record change through the v3 Employee update and partial update operations

Proposed actions are target capabilities. Every action runs propose-first and needs a validated deployment and the appropriate permissions.

What you can build

  • Fill a gap before the shift starts

    When a shift in GET /schedule/v3/shifts loses its employee to a new absence, the operator finds employees in the same group and proposes a replacement for the scheduler to confirm.

    With Shift Coverage

  • Stop leave from colliding with the schedule

    The operator reads absence schedules and the shifts already assigned in the same window and proposes which requests a manager should decline or move.

    With Leave Conflict

  • Staff for a forecast that changed

    Calculated forecasts and optimal headcounts per unit set the demand line. When a forecast event lifts it, the operator proposes extra shifts and records the forecast it relied on.

    With Event Surge

  • Watch labor against budget

    Uploaded budget data and scheduled shifts for a group give the week's plan. The operator proposes where hours run past budget and what to cut.

    With Labor Budget

Requirements

  • A Quinyx account with access to Account Settings → Integrations credentials to generate a client ID and secret
  • Scopes assigned to the credentials for each resource, such as hr:employees:read and schedule:shifts:read
  • The regional base URL for your data: api.eu.quinyx.com or api.na.quinyx.com, with rc hosts for testing
  • Group, unit, and employee identifiers, resolved from external IDs or badge numbers through the v2 Mapping API where needed
Authentication
OAuth 2.0 client credentials generated under Account Settings → Integrations credentials in Quinyx, exchanged at /oauth/v3/token for a Bearer token that expires after one hour.

Limits

  • Rate limits apply per customer and per endpoint group; exact v3 numbers and usage headers are not yet published, so 429 is retried with backoff
  • v3 lists are cursor paginated with pageToken; pageSize defaults to 50 and caps at 100
  • A calculated-forecast query cannot exceed 120 days, and absences can be created only at Unit level, not District or Domain
  • Absences are blocked once the salary period is transferred to payroll; at most two absences may overlap

Access and pricing

Reference listing. Fibric builds the connector under a managed deployment when you request it. Your quote covers the build, capabilities, usage, and support.

Request Quinyx ↗

Questions and answers

Which Quinyx API version should a new integration use?
Quinyx marks API v3 as recommended for new integrations. v3 covers OAuth access tokens, groups, roles, employees, role assignments, and shift listing. v2 remains documented for absences, forecasts, mappings, opening hours, and other resources. v1 is a legacy SOAP API kept for existing integrations.
Is there a test environment?
Yes. The Release Candidate environment at api.eu.rc.quinyx.com and api.na.rc.quinyx.com holds your organization's Production data up to the end of the previous month, refreshed on the first of each month. RC and Production each issue their own credentials.
How are time zones handled?
Timestamps default to UTC in RFC 3339 format. Send a Prefer header such as Prefer: timezone=Europe/Stockholm to receive times in another zone; the API confirms it with Preference-Applied.
Ask about Quinyx

Ask about the capabilities and requirements in this listing.

For project-specific requirements, contact Fibric.

This connector listing is developed, published, and supported by Fibric. It describes integration with Quinyx through published interfaces. Third-party names and logos identify the systems an integration connects to; they are the property of their respective owners, who are not affiliated with Fibric and do not sponsor or endorse this listing. Trademark policy