Ellipse Gradient for Header

Deputy Integration Guide

Connect Deputy workforce, scheduling, attendance, and leave data with enterprise applications through REST APIs, OAuth 2.0, and selected webhook notifications.

Deputy integration options at a glance

Deputy provides a REST API for workforce-management data, including Employees, Locations, Rosters, Timesheets, Leave, and Tasks. Applications use OAuth 2.0 authorization and bearer access tokens, with permissions determined by the Deputy organization and application configuration. Deputy also supports webhook-style notifications for selected resources and events, although coverage should be confirmed for each use case. Martini can consume Deputy REST endpoints, receive supported notifications through an exposed API or workflow trigger, paginate incremental retrievals, and apply mapping, validation, approval, and reconciliation rules. General-purpose GraphQL, SOAP, bulk, file, attachment, and direct database mechanisms were not confirmed.

Integration pointSupported by Deputy?Common use casesHow Martini supports it
REST APIsYesRetrieve and manage Deputy Employees, Locations, Rosters, Timesheets, Leave, and Tasks, subject to resource-specific permissions and operations.Martini can consume Deputy REST endpoints from workflows, map responses, apply business rules, and expose normalized APIs to other systems.
Webhooks / outbound callbacksLimitedReceive notifications for selected Deputy resource changes or events. Coverage, payloads, and availability must be confirmed for each resource.Martini can expose an API endpoint or use a webhook-consuming workflow, then retrieve the current Deputy resource and process the latest state.
AuthenticationYesDeputy applications use OAuth 2.0 authorization, client credentials, and bearer access tokens governed by organization and application permissions.Martini can manage OAuth-related configuration and store client secrets, tokens, and environment-specific values securely.
Pagination and incremental retrievalYesRetrieve large Employee, Roster, Timesheet, Leave, or Task populations through paging, filtering, and update-time strategies where supported.Martini workflows can persist cursors or timestamps, process bounded pages, and resume after interruptions.
Scheduled synchronizationYesRun recurring workforce, roster, attendance, leave, or payroll reconciliation workflows when event coverage is incomplete or a batch process is preferred.Martini scheduler-triggered workflows can retrieve changes, apply transformations, and reconcile missed or late updates.
Bulk / async / batch APIsNot confirmedA generally available Deputy bulk or asynchronous API should not be assumed for new integrations.Martini can implement bounded REST batches with paging, filtering, rate-limit-aware retries, and persisted progress instead.
File / attachment APIsNot confirmedA general-purpose Deputy file or attachment API was not confirmed in the reviewed official material.Martini should use confirmed Deputy REST resources or officially supported export mechanisms rather than assuming file transfer support.
GraphQL APIsNot confirmedNo official Deputy GraphQL API was confirmed.Martini integrations should use Deputy REST APIs and supported webhook mechanisms for the researched scope.
SOAP APIsNot confirmedNo official Deputy SOAP API was confirmed.Martini should not design the Deputy integration around SOAP unless Deputy separately confirms such an endpoint.

How Deputy exposes data and business events

Deputy REST APIs

Deputy’s primary documented integration mechanism is a REST-based API for workforce and scheduling resources. Applications can access resources such as Employees, Locations, Rosters, Timesheets, Leave, and Tasks according to the application’s authorization and resource permissions.

Martini implementation pattern

Martini implementation pattern: a workflow authenticates with OAuth 2.0, calls the required Deputy REST endpoints, handles pagination and transient failures, transforms the response into a canonical model, applies approval and validation rules, and writes the result to one or more target systems.

Implementation sequence

Store Deputy OAuth configuration and secrets
Request or use an authorized bearer access token
Call the required Deputy REST resource
Process paginated or incrementally filtered results
Map Deputy fields to the target model
Apply validation, approval, and business rules⁣

Deputy Webhook Notifications

Deputy supports webhook-style notifications for selected resource changes and events. Notifications are not a complete event stream for every object or operation, and coverage and payload completeness should be confirmed for the resources in scope.

Martini implementation pattern

Martini implementation pattern: expose a controlled API endpoint or webhook-consuming workflow, validate the notification, use an event or resource key for idempotency, retrieve the current Deputy resource, and route the latest state to downstream systems. Scheduled reconciliation should cover missed or unsupported events.

Implementation sequence

Receive the Deputy notification
Validate the request and identify the resource
Check the notification or resource idempotency key
Retrieve the current Deputy resource
Apply mapping and downstream business rules
Write the update and record processing status

Scheduled Incremental Synchronization

Deputy data can be retrieved on a schedule using supported filtering, paging, and update-time fields. This pattern is useful for large populations, payroll exports, and reconciliation where webhook coverage is partial.

Martini implementation pattern

Martini implementation pattern: a scheduler-triggered workflow loads the last successful cursor or timestamp, retrieves bounded pages, overlaps the time window to accommodate clock skew and late changes, processes each page, and advances synchronization state only after successful target writes.

Implementation sequence

Start the scheduled synchronization workflow
Load the persisted cursor or last-successful timestamp
Retrieve filtered and paginated Deputy resources
Process each bounded page
Apply duplicate and approval checks
Write target records and persist the new checkpoint

Common Deputy integration patterns

Pattern 1: Export approved Timesheets to payroll

When to use this pattern

Use this pattern when payroll or finance systems require approved or finalized Deputy time data. The workflow should exclude unapproved Timesheets, preserve Deputy identifiers, and support reconciliation when a previously exported Timesheet changes.

Integration direction
Deputy
Martini
Payroll or finance application
Example Mapping
Deputy FieldCanonical FieldTarget Field
Timesheet.EmployeeemployeeExternalIdemployeeId
Timesheet.LocationlocationExternalIdworkLocationId
Timesheet.StartTimeworkedStartperiodStart
Timesheet.EndTimeworkedEndperiodEnd
Martini implementation pattern

A scheduled Martini workflow retrieves paged Timesheets, filters for the required approval or payroll state, resolves Employee and Location mappings, normalizes time zones, and sends transformed records to the target API. It stores export status and Deputy identifiers, rejects incomplete mappings, and retries transient failures without creating duplicate payroll entries.

Martini capabilities used
  • scheduled workflows
  • API consumption
  • pagination
  • data mapping
  • business rules
  • idempotency
  • error handling

Pattern 2: Synchronize Employees and Locations

When to use this pattern

Use this pattern to keep HR, identity, payroll, finance, or operational platforms aligned with Deputy workforce identity and workplace data. It supports new employees, changes to employment details, Location assignments, and inactive employees.

Integration direction
Deputy
Martini
HR or identity application
Example Mapping
Deputy FieldCanonical FieldTarget Field
Employee.IdemployeeExternalIdexternalEmployeeId
Employee.DisplayNamefullNamename
Employee.StatusemploymentStatusstatus
Location.IdlocationExternalIdworkLocationId
Martini implementation pattern

Martini retrieves Employees and Locations incrementally, matches stable external identifiers, applies field and status transformations, and creates or updates target profiles. Business rules determine how inactive or terminated Employees are handled, while failed records are isolated for correction and replay.

Martini capabilities used
  • REST API consumption
  • incremental synchronization
  • data mapping
  • validation
  • business rules
  • reusable workflows
  • error handling

Pattern 3: Distribute Rosters to operations

When to use this pattern

Use this pattern when planning, communications, field operations, or downstream workforce systems need current Deputy shift assignments. It is suitable for recurring schedule distribution and reconciliation of last-minute changes.

Integration direction
Deputy
Martini
Operations or planning application
Example Mapping
Deputy FieldCanonical FieldTarget Field
Roster.EmployeeassignedEmployeeIdworkerId
Roster.LocationworkLocationIdsiteId
Roster.StartTimeshiftStartstartAt
Roster.EndTimeshiftEndendAt
Martini implementation pattern

A Martini workflow retrieves paginated Rosters, joins Employee and Location references, normalizes location-sensitive timestamps, and sends shift data to the target application. It uses deterministic keys for updates, handles canceled or changed shifts, and records rejected mappings for targeted retry.

Martini capabilities used
  • scheduler trigger
  • API consumption
  • data enrichment
  • time-zone transformation
  • business rules
  • idempotent updates
  • monitoring

Pattern 4: Process selected Deputy change notifications

When to use this pattern

Use this pattern for near-real-time reactions to Deputy resources or events covered by its webhook facilities. Because webhook coverage may be partial and notifications may be duplicated or delayed, pair it with scheduled reconciliation.

Integration direction
Deputy
Martini
Downstream application
Example Mapping
Deputy FieldCanonical FieldTarget Field
Webhook resourceIdsourceResourceIdexternalId
Webhook eventTypechangeTypeeventType
Employee or Timesheet statecurrentResourceStatenormalizedPayload
Martini implementation pattern

Martini receives the notification through an exposed API endpoint or webhook-consuming workflow, validates it, checks an idempotency key, and retrieves the current Deputy resource rather than relying on an incomplete payload. It then applies routing and validation rules, updates the target, and schedules reconciliation for missed or unsupported changes.

Martini capabilities used
  • API exposure
  • webhook consumption
  • workflow orchestration
  • API retrieval
  • idempotency
  • business rules
  • retry and reconciliation

Applications commonly integrated with Deputy

Deputy workforce data can be coordinated with payroll, accounting, point-of-sale, HR, identity, and operational platforms. Availability and field compatibility depend on the Deputy tenant, region, plan, and target application APIs, so each relationship should be validated during solution design.

Application Scenario Direction Martini Pattern
Xero Transfer approved Timesheets, employee information, and payroll-related data into accounting and finance processes. Deputy → Martini → Xero A scheduled Martini workflow retrieves approved Timesheets and Employees, maps identifiers and worked-time fields to Xero’s supported API model, validates export status, and records rejected items for replay.
QuickBooks Online Connect Deputy employee and time information with accounting and payroll workflows. Deputy → Martini → QuickBooks Online Martini retrieves finalized Deputy Timesheets, applies employee and Location mapping rules, transforms the payload for QuickBooks Online, and uses stable Deputy identifiers to prevent duplicate exports.
MYOB Support payroll and accounting processes using Deputy Employees, Locations, and Timesheets, particularly in Australia and New Zealand. Deputy → Martini → MYOB A Martini workflow synchronizes employee keys and approved time data, converts regional time and payroll fields, validates required mappings, and routes failures to an operator-controlled retry path.
ADP Transfer employee master data and worked-time information into payroll processing. ADP → Martini → Deputy Martini can receive or retrieve employee data from ADP, match it to Deputy Employees, and then send approved Deputy Timesheets to ADP after applying status, Location, and duplicate checks.
Lightspeed Align workforce scheduling and time tracking with retail or hospitality point-of-sale operations. Lightspeed → Martini → Deputy Martini orchestrates operational context from Lightspeed with Deputy Rosters and Locations, normalizes identifiers and time zones, and distributes validated workforce data to payroll or planning systems.
Square Coordinate workforce scheduling and time tracking with point-of-sale operations. Square → Martini → Deputy A Martini workflow maps Square operational context to Deputy Employees, Locations, and Rosters where required, then reconciles Deputy attendance and time data with downstream payroll processes.
Salesforce Synchronize workforce, location, or service-operation data with CRM and field-service processes. Salesforce → Martini → Deputy Martini exposes or consumes REST APIs to synchronize selected Deputy Employees, Locations, and Tasks with Salesforce objects, applying field mappings, validation rules, and retry handling.
Workday Align employee master data and workforce records across enterprise HR and workforce-management platforms. Workday → Martini → Deputy Martini compares Workday employee data with Deputy Employees, maintains cross-system identifiers, routes approved Deputy time data back to HR or payroll processes, and handles inactive or terminated employees according to business rules.

How to build a Deputy integration in Martini

Objective

Establish Deputy OAuth 2.0 authorization and configure the target application credentials without embedding secrets in workflows or source-controlled mappings.

Instructions in Martini

  • Create the Deputy application authorization configuration
  • Store client credentials, tokens, and endpoint values in Martini secrets or environment configuration
  • Confirm Deputy organization, user, and resource permissions
  • Configure target-system authentication separately

Objective

Select a scheduler, webhook endpoint, or API entry point based on the required latency, event coverage, and reconciliation strategy.

Instructions in Martini

  • Use a scheduler for incremental synchronization and payroll exports
  • Use a webhook-consuming workflow for supported Deputy notifications
  • Expose a Martini API when another application should initiate processing
  • Pair event-driven flows with scheduled reconciliation where coverage is partial

Objective

Read the required Deputy resources while accounting for pagination, filtering, incremental windows, and resource-specific permissions.

Instructions in Martini

  • Call the required Deputy REST endpoint
  • Process bounded pages rather than loading full populations
  • Persist a cursor or last-successful timestamp
  • Use an overlap window for clock skew and late-arriving changes

Objective

Coordinate retrieval, enrichment, validation, transformation, target writes, and checkpoint management in a maintainable Martini workflow.

Instructions in Martini

  • Resolve Employee and Location references when required
  • Separate transient API failures from authorization and validation failures
  • Advance synchronization state only after successful processing
  • Use reusable workflow logic for common resource handling

Objective

Convert Deputy objects into canonical and target-specific models while preserving identifiers, approval state, and time-zone context.

Instructions in Martini

  • Map Employees, Locations, Rosters, Timesheets, Leave, or Tasks explicitly
  • Normalize regional timestamps with Location context
  • Preserve Deputy identifiers as external keys
  • Transform JSON payloads to the target API model

Objective

Enforce business controls such as payroll approval, inactive employee handling, duplicate prevention, and required-field validation before writes.

Instructions in Martini

  • Export only approved or finalized Timesheets when required
  • Validate Employee and Location mappings
  • Reject incomplete or incompatible records with clear diagnostics
  • Prevent repeated creates using deterministic external keys

Common Deputy data objects used in integrations

ObjectTypical UseCommon target systemsMartini handling
EmployeeSynchronize employee profiles, employment details, workforce identity, status, and Location assignments.HR, payroll, identity, finance, and operational platformsMartini retrieves Employees through the REST API, matches stable identifiers, maps status and assignments, and applies create, update, and inactive-employee rules.
LocationRepresent workplaces, stores, sites, and operational locations used by schedules and attendance processes.Payroll, finance, retail operations, planning, and reporting systemsMartini normalizes Location identifiers and time-zone context, then links Locations to Employees, Rosters, and Timesheets during transformation.
RosterRepresent scheduled shifts, employee assignments, breaks, and schedule status.Planning, operations, workforce communication, payroll, and reporting systemsMartini retrieves paged Rosters, converts dates and time zones, distributes shift changes, and reconciles updates using Deputy identifiers.
TimesheetRepresent clock-in, clock-out, attendance, worked-time, approval, and payroll-related information.Payroll, accounting, finance, HR, and data platformsMartini filters for approved or finalized Timesheets, validates Employee and Location mappings, prevents duplicate exports, and stores processing status.
LeaveRepresent employee leave requests and leave records.HR, payroll, workforce planning, and employee operations platformsMartini retrieves Leave data, maps statuses and dates, applies policy or approval rules, and synchronizes changes incrementally.
TaskRepresent operational work items assigned within Deputy.CRM, service operations, planning, and reporting platformsMartini maps Task assignments and statuses to target work models, applies routing rules, and records failures for selective replay.

Authentication and security considerations

OAuth 2.0 authorization

Deputy applications use OAuth 2.0 authorization and bearer access tokens. The available resources and operations depend on the Deputy organization, user, application configuration, and granted permissions.

Secret management

Store Deputy client credentials, access tokens, refresh data, and endpoint configuration in Martini secrets or environment configuration. Do not place credentials in mappings, payloads, or source-controlled workflow definitions.

Controlled API exposure

When receiving Deputy webhook-style notifications, expose only the required Martini API surface and validate incoming requests before using notification data to retrieve or update resources.

Operational considerations for Deputy integrations

Pagination and incremental state

Process Deputy resources in bounded pages and persist a cursor or last-successful timestamp. Use overlap windows to account for clock skew, late changes, and records modified during a synchronization run.

Rate limits and retries

Use bounded retries with exponential backoff for transient failures and throttling responses. Retry logic must remain idempotent so repeated requests do not create duplicate exports or target records.

Webhook reconciliation

Webhook coverage is resource-specific. Tolerate duplicate and out-of-order notifications, retrieve the latest resource state, and run scheduled reconciliation for missed or unsupported changes.

Payroll state and time zones

Export Timesheets only when required approval or payroll-finalization conditions are met. Preserve Location and time-zone context when processing Rosters, attendance, and worked-time data across regions.

Schema and regional differences

Deputy fields, resource behavior, partner applications, and available functionality may vary by country, plan, and tenant configuration. Isolate mappings from business rules and monitor Deputy documentation for changes.

Why use Martini instead of scripts or point-to-point integrations?

Orchestrate complete integration flows

Scripts often combine authentication, paging, transformation, retries, and target writes in one code path. Martini provides workflow orchestration so these concerns can be separated into understandable, reusable integration behavior.

Support multiple synchronization modes

Martini can consume Deputy REST APIs, receive supported webhook notifications, expose APIs, and schedule reconciliation workflows. This supports real-time-style updates where available without abandoning reliable batch synchronization.

Make mappings and controls maintainable

Deputy Employees, Locations, Rosters, Timesheets, Leave, and Tasks can be mapped to canonical and target-specific models with explicit validation, approval rules, idempotency, and error handling.

Improve operational reliability

Centralized workflows can persist checkpoints, isolate failed identifiers, apply bounded retries, and provide a controlled replay path instead of requiring operators to rerun an entire script or maintain multiple point-to-point integrations.

Frequently asked questions

How can Deputy be integrated with enterprise systems?

Deputy can be integrated through its REST API using OAuth 2.0 and bearer access tokens. Selected Deputy resource changes can also generate webhook-style notifications. Enterprise workflows commonly retrieve Employees, Locations, Rosters, Timesheets, Leave, and Tasks incrementally, transform them, apply business rules, and send them to payroll, HR, finance, operations, or reporting systems.

Can Martini integrate with Deputy?

Yes. Martini can consume Deputy REST APIs using OAuth 2.0, process paginated and incremental responses, and receive supported Deputy webhook notifications through an exposed API or workflow trigger. Martini can then map Deputy objects into downstream application models and orchestrate validation, reconciliation, and error handling.

Do I need a connector to integrate Deputy with Martini?

No. A dedicated Deputy connector is not required. Martini can integrate with Deputy using Deputy’s native REST API, OAuth 2.0 authentication, supported webhook notifications, and the resource-specific paging and filtering mechanisms documented by Deputy.

Is there any extra Lonti cost to integrate Deputy with Martini?

Lonti does not charge an additional per-connector or per-vendor fee to integrate Deputy. The integration is subject to the provisioned capacity of the Martini environment. Separate costs may apply from Deputy, cloud infrastructure, payroll providers, or other third-party systems depending on subscriptions, usage, and deployment model.

Which Deputy integration methods should new solutions use?

Deputy REST APIs and OAuth 2.0 are the primary confirmed mechanisms for new integrations. Webhook-style notifications can support selected event-driven scenarios, but coverage should be verified for each resource. No official Deputy GraphQL or SOAP API, general-purpose bulk API, file API, or direct database access was confirmed.

Are Deputy webhooks available for real-time integration?

Deputy supports webhook-style notifications for selected resources or events, but they should not be treated as a complete event stream. Martini can receive notifications, retrieve the current Deputy resource, and update downstream systems. Scheduled reconciliation is recommended for important data because notifications may be duplicated, delayed, or unavailable for some changes.

How does Martini synchronize and transform Deputy data?

Martini can run scheduled or event-driven workflows that retrieve paginated Deputy resources, maintain a cursor or timestamp, map objects such as Employees and Timesheets to canonical models, normalize time zones, and apply approval or status rules. Stable Deputy identifiers can be retained as external keys for updates and duplicate prevention.

How are Deputy errors, retries, and duplicates handled?

Martini can separate transient API failures, throttling, authorization problems, validation failures, and business-state errors. Bounded retries with backoff can be used for transient failures, while idempotency keys and stable Deputy identifiers prevent duplicate downstream creates. Failed identifiers and response details can be persisted for selective replay and reconciliation.