Reference · built on requestConnectorHR, scheduling & workforce

Deputy

Rosters, timesheets, employees, leave, and sales metrics from your Deputy install, with a webhook for every resource event.

Request accessPricing ↗

About

Deputy is a workforce management platform for rostering, time and attendance, and leave. Every customer runs on its own subdomain in the AU, EU, UK, or US region, and the API lives at that install's /api/ path. Most endpoints sit under /api/v1; Agreed Hours and Sales Metrics use /api/v2. Responses are JSON with a maximum of 500 records each.

Through Fibric, an operator queries rosters and timesheets through the Resource API, receives webhooks as timesheets start and end, and proposes a shift, a timesheet approval, or an open-shift offer. A person approves. The change is applied once and a receipt is kept.

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

  • Rosters by date, employee, or area through POST /api/v1/resource/Roster/QUERY; default reads cover the previous 12 and next 36 hours
  • Timesheets with TimeApproved, PayRuleApproved, Exported, and ValidationFlag through POST /api/v1/resource/Timesheet/QUERY
  • Employees and their agreements through /api/v1/resource/Employee, with the caller's identity from GET /api/v1/me
  • Leave requests through /api/v1/resource/Leave and shift swaps through /api/v1/resource/RosterSwap
  • Sales and other metrics by area and time through GET /api/v2/metrics/raw, including plan_ and forecast_ series
  • Webhooks with a topic and data payload for any resource insert, update, or delete, filterable by field such as IsInProgress

Proposed actions

  • Target capability: propose a shift through POST /api/v1/supervise/roster and its publication through /api/v1/supervise/roster/publish
  • Target capability: propose approving, updating, or discarding a timesheet through the /api/v1/supervise/timesheet endpoints
  • Target capability: propose a leave request for manager approval through POST /api/v1/resource/Leave
  • Target capability: propose an open-shift offer to named employees through POST /api/management/v2/shifts/offers:notify

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

What you can build

  • Fill an open shift fast

    When a roster query shows an unfilled published shift, the operator proposes the eligible employees to notify through shifts/offers:notify. A manager approves and the offer goes out once.

    With Open Shift Offer

  • Review swap requests with context

    RosterSwap records show who asked to swap and who accepted. The operator checks agreements and hours and proposes approve or decline with the reason.

    With Swap Review

  • Approve timesheets with exceptions first

    Timesheets with a ValidationFlag set are surfaced before the pay run. The operator proposes an update or approval through /supervise/timesheet for each one.

    With Timesheet Signoff

  • Keep coverage in line with sales

    Sales metrics from /api/v2/metrics/raw are compared with rostered hours by area. The operator proposes where to add or remove a shift and records the numbers.

    With Labor Budget

Requirements

  • A Deputy install and its region, for example https://{install}.au.deputy.com
  • A permanent token for one install, or a client ID and secret registered at once.deputy.com for many
  • For signed webhooks, an Enterprise install's private key from Enterprise > Advanced Settings
  • A receiving endpoint for webhook POSTs, ideally behind a queue such as AWS SQS as Deputy recommends
Authentication
A permanent token created per install at /exec/devapp/oauth_clients, or OAuth 2.0 authorization code flow through once.deputy.com with scope longlife_refresh_token; access tokens last 24 hours and are sent as a Bearer header.

Limits

  • A single response holds at most 500 records; use Resource API queries with date and employee filters to page through more
  • Timesheets fire webhooks at start, pending, time approval, and pay approval; filter to the events you need
  • Shift offer notifications may send SMS and incur SMS fees in the client's Deputy account
  • Confidential employee fields such as tax file numbers need the Advanced Employee API and an additional security check

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 Deputy ↗

Questions and answers

Where is the Deputy API endpoint?
On your own install. If your Deputy is at https://simonssambos.au.deputy.com, the API is https://simonssambos.au.deputy.com/api/. Installs sit in the AU, EU, UK, or US region, so do not assume one. Premium and Enterprise share the same endpoints.
How do webhooks work in Deputy?
Any resource can have a webhook for insert, update, or delete, one webhook per action. Deputy POSTs JSON with topic and data plus X-Deputy-Webhook-Callback and X-Deputy-Generation-Time headers. Enterprise installs also get X-Deputy-Secret, an HMAC-SHA256 of the body. There is no limit on webhooks per install.
Permanent token or OAuth?
A permanent token suits one or two installs or an internal connection; it is shown once and sent as a Bearer header. OAuth 2.0 through once.deputy.com suits apps used across many installs, with 24-hour access tokens refreshed through a long-life refresh token.
Ask about Deputy

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 Deputy 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