Skip to content
Docs

GraphQL schema

The Temprix API is one GraphQL schema, the same one the app is built on. The reference pages in this section are generated from it and list every operation and type. This page is the map: what each reference section holds, the patterns that repeat everywhere, and which operations to start from for the tasks most integrations need first.

Reference sections

Section titled “Reference sections”
Section Contains Open it for
Query Every read operation The arguments a lookup or list accepts, and what it returns
Mutations Every write operation Create, update and delete, and the input each one takes
Objects Types the API returns The fields available on a member, event, team or rule
Inputs Types mutations accept Which fields are required when writing
Enums Fixed value sets Allowed values, such as RecurrenceChangeFlag
Scalars Primitive formats How dates, timestamps, URLs and JSON are encoded

Operations that require a signed-in session are omitted from the Query and Mutations pages in the reference when using an API key. Those calls return an authorisation error for a key.

References by ID

Section titled “References by ID”

Objects carry the IDs of related records, not the records themselves. A MemberEvent has a memberId and an eventTypeId. There is no nested member field to select.

To resolve references, ask for the related root fields in the same request. One request can hold several root fields, so one round trip is usually enough:

query OctoberLeave {
  memberEvents(
    between: { from: "2026-10-01", to: "2026-10-31" }
    eventTypeIdIn: ["1001"]
  ) {
    items {
      memberId
      startDate
      endDate
      availability
    }
    nextToken
  }
  members {
    items {
      id
      displayName
    }
    nextToken
  }
}

Match memberId against members.items[].id in client code. When only a few records are needed, pass their IDs to idIn instead of listing everything.

Lookups and lists

Section titled “Lookups and lists”

Most entities have two root fields. The singular one takes an id and returns the record, or null if it does not exist or cannot be seen: member, team, eventType. The plural one returns a list: members, teams, eventTypes. Most plural fields accept idIn for batch lookup. Leave it out to list everything the key can see.

Every list returns an envelope: the records in items, and a nextToken for the next page. Keep requesting until nextToken is null. The loop, and why an empty page is not the end, are on Conventions.

Date ranges

Section titled “Date ranges”

Arguments named between take one of two inputs:

  • PlainDateRange takes calendar dates such as 2026-10-01. Member events, group events and coverage use it, because they are whole days. Both ends are included.
  • DateRange takes timestamps. The audit log and notification history use it, because they record moments.

Calendar-date ranges are inclusive at both ends. Timestamp ranges are half-open. A one-day event uses startDate === endDate. Further rules are on Conventions.

Writes

Section titled “Writes”

Create and update mutations take their fields in one input argument, for example createMemberEvent(data: …). Updates also take the record’s id. Deletes return a payload with the deleted record’s id.

Every write is recorded in the audit log against the member whose key made it.

Common tasks

Section titled “Common tasks”
To Start with Worth knowing
List the people on a team teamMembers(teamId), then members(idIn) TeamMember links a member to a team and holds their role on it. A member can be on several teams, or none.
Find who is away in a period memberEvents Pass memberIdIn, eventTypeIdIn, or both. At least one is required.
Find holidays and closures affecting people groupEvents Group events belong to the workspace and match members by location, not by team. See Group events.
Turn event type IDs into names eventTypes(idIn), eventCategories(idIn) A type with no defaultAvailability of its own inherits it from its category.
Read a team’s forward coverage coverageOutlook Forward-looking only, up to 180 days. See Coverage below.
Book leave or another event createMemberEvent availability runs from 0.0 (fully away) to 1.0. Recurring series are created with the same mutation.
Change part of a recurring series updateMemberEvent, deleteMemberEvent flag chooses the scope: all, this, or fromThis. Deleting one occurrence returns the updated series, not a deleted id.
Read a team’s alert rules teamNotificationRules(teamId) Rules carry their schedule and last run, such as nextInvokeAt, lastRunStatus and lastRunCode.
See why an alert did or did not send notificationDispatches, teamNotificationRuleEvals A send is recorded as a dispatch. A run that sent nothing, or failed, is recorded as an eval with a code.
See who changed what auditEvents Filter by entity, author or type. Newest first.

Worked versions of the most common integrations are on Examples.

Main types

Section titled “Main types”
Type What it is
Workspace The tenant. Every request runs inside one workspace, taken from the key.
Member A person in the workspace, signed in or not. Holds baseline availability and location.
Team A group that coverage is planned for, with an optional coverage target.
TeamMember The link between a member and a team, with the member’s role on that team.
EventCategory Shared behaviour for a set of event types: default availability, time type, colour.
EventType The label chosen when an event is logged, such as Annual Leave.
MemberEvent Whole days on one member’s calendar with an availability value. May recur.
GroupEvent Days that apply to every member in a location, such as a public holiday.
CoverageOutlook A team’s forward coverage, one period per day, week or month.
TeamNotificationRule A coverage alert rule for one team: threshold, window, schedule and channels.
NotificationDispatch One notification that was sent, with the outcome per channel.
AuditEvent One recorded change, with its author and time.

Coverage

Section titled “Coverage”

coverageOutlook returns the figure plotted in Coverage Outlook for one team. How the figure is produced is on How coverage is calculated.

  • Range. between can start at most seven days before today, in UTC, and span up to 180 days. Earlier starts fail with COVERAGE_HISTORY_REQUIRED. Coverage for past periods is not available over the API.
  • Granularity. day (the default), week or month. A week or month value is the average of the included days in it.
  • Days. daysOfWeek chooses which weekdays are included, as ISO numbers from 1 (Monday) to 7 (Sunday). Leave it out to use the workspace’s working days.
  • Two numbers per period. coverage is always in people. value is the same figure expressed in the coverageMetric requested, such as a percentage or the gap against target.