Introduction

The 7shifts API gives you programmatic access to the scheduling, labor, sales, and employee data behind a restaurant's 7shifts account. Use it to push sales from a POS, pull worked hours into payroll, sync employees from an HR system, or feed a data warehouse.

Everything runs over a REST API at https://api.7shifts.com/v2. If you have a 7shifts account, you can make your first call in about five minutes.

Make your first call

1. Create an access token. In 7shifts, go to Company Settings → Developer Tools. Any company admin can create one; there is no approval step. Full instructions are in the Authentication guide.

2. Find your company ID.

curl --request GET \
  --url 'https://api.7shifts.com/v2/companies' \
  --header 'Authorization: Bearer {ACCESS_TOKEN}' \
  --header 'x-api-version: 2026-01-01'

The id in the response is your {COMPANY_ID}. Nearly every other endpoint is scoped to it.

3. Read something real.

curl --request GET \
  --url 'https://api.7shifts.com/v2/company/{COMPANY_ID}/locations' \
  --header 'Authorization: Bearer {ACCESS_TOKEN}' \
  --header 'x-api-version: 2026-01-01'

A 200 with your restaurants in the data array means you are ready to build.

Send x-api-version on every request. Tokens carry a default version, and when that default differs from the one you built against you get failures that are hard to trace. See Versioning.

Pick your path

What you are building determines which guides matter. Most integrations are one of these five.

Building an internal tool, a report, or a one-off script for your own restaurant group is a valid path too. Skip the guides and go straight to the API reference.

Choose an authentication method

Create an access token. Any 7shifts customer can make one for their own company, it takes minutes, and it can do everything the API supports for that company.

OAuth clients are a different credential, issued only to vetted 7shifts partners after commercial review and technical certification. They exist so a single integration can serve many customers. You need one only if you are distributing a product that other 7shifts customers will connect to their own accounts.

graph TD
    A[Whose 7shifts data<br/>are you accessing?] --> B[My own company,<br/>or one client's]
    A --> C[Many customers who<br/>connect my product]
    B --> D[Access token<br/>Create it yourself, minutes]
    C --> E[Apply to the<br/>7shifts partner program]
    E --> F[After review and certification,<br/>7shifts issues an OAuth client]

If you are not sure, use an access token. You can build a complete production integration with one. See Authentication.

How a 7shifts account is shaped

Almost every endpoint is scoped to a company, and most data hangs off a location. Understanding this hierarchy before you write code saves the most common class of integration bug.

graph TD
    C[Company<br/>the customer's account] --> L[Location<br/>a physical restaurant]
    L --> D[Department<br/>e.g. kitchen, front of house]
    D --> R[Role<br/>e.g. server, line cook]
    L --> R2[Role<br/>attached directly to a location]
    R --> U[User]
    R2 --> U

Two things surprise people. A role attached directly to a location returns department_id of 0, not null. And "user" is the API object while "employee" is the person — the docs keep them distinct, and so should your code.

Before your integration can move data, you have to decide which record in your system corresponds to which record in 7shifts. That process is Mapping, and it is worth reading early.

For everything else, see the Glossary.

Conventions

Details are in Pagination and Errors.

Before you build

Check plan requirements. Some endpoints depend on features a company has enabled. An integration that works against your account can return empty data against a customer on a different plan. See Plan requirements.

Keep credentials server-side. The API supports CORS, so browser requests work. Do not use that to ship a real credential to a browser. Tokens and OAuth client secrets belong on your server. If one is exposed, rotate it immediately.

Prefer webhooks over polling where you can. Events cover schedule publishing, time punches, user changes, and payroll period closing. See Webhooks.

Expect editing after the fact. Managers change published schedules and correct time punches retroactively. A forward-only sync will drift. Re-read a trailing window rather than only new records.

Where to go next

Using the 7shifts API means agreeing to the 7shifts API Terms of Use.