Reference · built on requestConnectorHR, scheduling & workforce

7shifts

Locations, departments, roles, users, shifts, time punches, and sales receipts from 7shifts, with webhooks for schedules and punches.

About

7shifts is a scheduling, time clock, and labor platform for restaurants. Its REST API at https://api.7shifts.com/v2 scopes nearly every call to a company, with locations, departments, and roles below it and users holding roles across locations. List endpoints page with limit and cursor, and every request carries an x-api-version header.

Through Fibric, an operator reads published shifts, time punches, and receipts by location, reacts to time_punch and schedule.published webhooks, and proposes a shift, a punch correction, or a receipt import. You sign off. The change is sent once with a record of what changed.

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

  • Locations, departments, and roles through GET /v2/company/{company_id}/locations, /departments, and /roles
  • Users with role and location assignments and wages through GET /v2/company/{company_id}/users
  • Shifts by location, department, role, user, date range, and modified_since through GET /v2/company/{company_id}/shifts, with draft and open filters
  • Time punches with approval status, breaks, and business dates through GET /v2/company/{company_id}/time_punches
  • Payroll periods and their closed state through GET /v2/time_clocking/payroll_periods
  • Sales receipts by location and date through GET /v2/company/{company_id}/receipts
  • Webhooks for schedule.published, time_punch.created, edited, and deleted, user changes, and payroll_period.closed

Proposed actions

  • Target capability: propose creating or updating a shift through POST and PUT /v2/company/{company_id}/shifts
  • Target capability: propose a time punch correction through the Update Time Punch endpoint
  • Target capability: propose importing a sales receipt through POST /v2/company/{company_id}/receipts
  • Target capability: propose approving or declining a time off request through the Time Off endpoints

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

What you can build

  • Rebalance the floor inside a shift

    Time punches show who is clocked in and receipts show sales by location. The operator proposes cutting or extending shifts as the day runs and records the sales behind it.

    With Intraday Balance

  • Keep labor cost inside budget

    Daily sales and labor read together set the ratio. The operator proposes schedule changes where projected labor exceeds the target you set.

    With Labor Budget

  • Close punches before the pay period

    payroll_period.closed and the time_punches endpoint show unapproved or flagged punches. The operator proposes each correction for a manager before export.

    With Timesheet Signoff

  • Check breaks were taken

    Time punches carry break records. The operator compares them with the company's labor settings and proposes which shifts need a manager's attention.

    With Break Compliance

Requirements

  • A 7shifts company and an admin to create the access token and serve as its technical contact
  • The company ID from GET /v2/whoami or GET /v2/companies, since nearly every endpoint is scoped to it
  • An HTTP endpoint that accepts unauthenticated POSTs and returns 2XX quickly, for webhooks configured in Developer Tools
  • Features enabled on the company's plan for the endpoints you call; some return empty data otherwise
Authentication
A long-lived access token created under Company Settings > Developer Tools, sent as Authorization: Bearer; OAuth clients with one-hour tokens and an x-company-guid header are issued only after 7shifts reviews the integrator.

Limits

  • 10 requests per second per token across all endpoints; a 429 means back off
  • Access tokens carry admin-level access to one company and cannot be scoped to resources or actions
  • Managers edit published schedules and punches after the fact, so re-read a trailing window rather than only new records
  • HMAC signature headers are present only on webhooks 7shifts configures, not on those set up in the web app

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

Questions and answers

Do I need an OAuth client to use the 7shifts API?
No. Any 7shifts customer can create an access token under Company Settings > Developer Tools with no approval step, and it can do everything the API supports for that one company. OAuth clients exist for integrations serving many customers and are issued only after 7shifts reviews the integration.
How do I keep a schedule copy in sync?
Subscribe to schedule.published and the time_punch webhooks, then re-read shifts with modified_since over a trailing window, because managers change published schedules and correct punches retroactively. Follow meta.cursor.next until it is null, and send x-api-version on every request.
How are webhook signatures checked?
Webhooks 7shifts configures include x-webhook-topic, x-company-id, x-hmac-timestamp, and x-hmac-signature headers. The signature is a SHA-256 HMAC of the payload keyed with {timestamp}#{guid}, where guid is the company's OAuth grant. Webhooks created in the web app carry no HMAC headers.
Ask about 7shifts

Ask about the capabilities and requirements in this listing.

For project-specific requirements, contact Fibric.