API reference

The link between your app and one business. Every access credential belongs to exactly one.

The business this connection is for.

The places a business operates. A location owns the timezone for everything that happens there.

The jobs people are rostered into at a location.

The public holidays each location observes, worked out the way Shiftly pays them, including days the business added or removed.

Jobs or cost centres that shifts and timesheets are recorded against. The business may call them something else in Shiftly. Archive a project by changing its status; projects are not deleted.

The people who work at the business. A person is added in Shiftly, not through the API. Someone who has left is an archived employment; their own record is no longer shared with the business.

A person's job at the business: when it started, on what basis, and (with the pay permission) what they are paid. An employment is created and ended in Shiftly.

One roster per location per week. Reading never creates one: a week nobody has rostered yet returns nothing. Rosters are published in Shiftly.

Rostered shifts. A shift your app creates is a draft until a manager publishes the roster in Shiftly. Any shift that has not started can be changed or deleted; a change to a published shift makes it a draft again until a manager republishes.

Staff at the shift's location who may work its position and are free: no overlapping shift, no approved or pending leave, and not unavailable. The list is not ranked.

Staff asking to work a published shift nobody holds. Managers decide them in Shiftly. A request is removed, not kept, when the shift is deleted or the person is given an overlapping shift.

Staff offering a shift to a named colleague, who accepts or declines in Shiftly. A cancelled offer is removed, not kept.

When people have said they can and cannot work. Each record is a rule that may repeat, not a list of days.

Shifts a venue offers to independent workers through Shiftly OnDemand. Your app can create, change and delete drafts. The venue sets the hourly rate and publishes each shift in Shiftly. Nothing about the worker is shared.

Worked time. A timesheet your app creates is pending until a manager approves it in Shiftly. Pay is always worked out by Shiftly.

Staff clocked in right now: one row per open timesheet started in the last 24 hours, earliest clock-in first. It says where a person is, so read it when you need it rather than polling it.

Hours, counts and cost of timesheets started in a date range, split into approved and pending. Rejected timesheets and timesheets still open are left out, and a range with none returns no rows. Totals are rounded once, so they can differ by a few cents from adding up each timesheet.

Rostered and actual hours and cost per calendar day and location, against the location's labour target. Rostered figures need rostering access and actual figures need timesheet access; costs need pay access. Days with no shifts or timesheets are left out. Sales are not included, so the labour percentage itself is yours to work out.

Requests for leave. A request your app submits is pending until a manager decides it in Shiftly. Dates are calendar days at the business's first location.

Periods when the business limits leave, such as a busy season. Dates are calendar days at the business's first location.

What leave a person has, by leave type. Worked out when you ask, so there is nothing to page through.

The kinds of leave this business offers and how each builds up.

The Fair Work awards this business pays under.