Reference · built on requestConnectorHR, scheduling & workforce

When I Work

Shifts, schedules, users, positions, time clock entries, and requests from When I Work, with webhooks for shifts, times, and swaps.

Request accessPricing ↗

About

When I Work is an employee scheduling and time clock application for hourly teams. Its REST API at https://api.wheniwork.com groups methods under Shifts, Schedules (Locations), Positions, Sites, Users, Times, Punch, Time Off Requests, Shift Requests, OpenShift Requests, Payrolls, and Shift Breaks. A separate Login Service issues tokens and a Webhooks Service streams change events.

Through Fibric, an operator reads shifts and time entries by date range, listens for shifts::updated and times::punch events, and proposes a new shift, an OpenShift assignment, or a clock-in. You say yes. The change is made once and recorded.

This is a reference listing. It documents what Fibric would read from When I Work 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

  • Shifts by user, schedule, and date range through GET /2/shifts, including open and unpublished shifts and swaps
  • Time entries from terminals, web, mobile, and edits through GET /2/times, with the current punch state at GET /2/punch/state
  • Users, positions, schedules (locations), and sites through GET /2/users, /2/positions, /2/locations, and /2/sites
  • Time off requests through GET /2/requests and shift drop or swap requests through GET /2/swaps
  • OpenShift approval requests through GET /2/openshiftapprovalrequests and payroll periods with totals through GET /2/payrolls
  • Scheduled and worked breaks through /v3/scheduled-breaks and /v3/shift-breaks
  • Webhook events such as shifts::created, times::punch, swaps::taken, and users::updated, streamed to a domain the account owns

Proposed actions

  • Target capability: propose one or many shifts through POST /2/shifts, then publish them through POST /2/shifts/publish
  • Target capability: propose assigning users to an OpenShift through POST /2/shifts/{id}/assign
  • Target capability: propose a clock-in or clock-out for a user through POST /2/times/clockin and /2/times/clockout
  • Target capability: propose a time off request through POST /2/requests

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

What you can build

  • Respond to a no-show

    Shifts show who is scheduled and times show who has punched. When a shift starts with no punch, the operator proposes the users to offer it to and the message to send.

    With No-Show Response

  • Fill open shifts by eligibility

    GET /2/shifts/eligible lists who can take an OpenShift. The operator ranks candidates by hours and position and proposes the assignment through /2/shifts/{id}/assign.

    With Open Shift Offer

  • Catch a forgotten clock-out

    A times::punch event with no matching clock-out by the shift end triggers a check. The operator proposes the clock-out time for a manager to confirm.

    With Missed Punch

  • Review shift swaps

    swaps::created events carry the request. The operator checks both users' hours and positions and proposes approve or deny through PUT /2/swaps/{swap_id}.

    With Swap Review

Requirements

  • A When I Work account and a private developer key obtained through the Help Center's API services guide
  • A user login in each workplace the operator will read; W-UserId picks the account when a person belongs to several
  • A TLS endpoint on a domain owned by the account to receive webhook events
  • The w-userid request header for Tasks, Work Tags, and Paid Rest endpoints
Authentication
A developer key sent as W-Key with a user's email and password to https://api.login.wheniwork.com/login returns a JSON Web Token, sent as a Bearer header with W-UserId selecting the workplace.

Limits

  • Rate limits use rolling windows and answer with 403 errors; When I Work recommends webhooks over frequent large pulls
  • Payrolls cannot be created or deleted through the API
  • Webhook events are delayed a few seconds for batching
  • Absences, scheduling rules, and break attestation are documented in separate Scheduling and Attendance API specs

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 When I Work ↗

Questions and answers

How does When I Work authentication work?
Post a user's email and password with your developer key in the W-Key header to https://api.login.wheniwork.com/login. The response holds a JSON Web Token you send as Authorization: Bearer. If the person belongs to more than one workplace, list users and set W-UserId to choose the account.
Which events do webhooks send?
The Webhooks Service lists users::created, users::invited, users::updated, users::deleted, shifts::created, shifts::updated, shifts::deleted, times::created, times::updated, times::deleted, times::punch, times::break, swaps::created, swaps::taken, swaps::updated, swaps::deleted, and schedules::created, updated, and deleted. Settings are managed through /settings/webhooks.
Can I write time entries?
Yes. POST /2/times creates a time record and POST /2/times/clockin or /2/times/clockout punches the current or another user, recording who created the punch. For accounts with Check payroll onboarded, a start time cannot fall after the end of the current pay period.
Ask about When I Work

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 When I Work 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