Performance API - Labelbox

The Performance API returns the numbers shown on a project’s Performance dashboard and on the workspace Monitor: throughput, time, and quality metrics over a period, and totals for each labeler and reviewer. Use it to bring those numbers into your own reporting. It also shows when your organization’s members signed in and out, and when they were active or idle in the editor: see Sign-in sessions and Active and idle periods. The API runs the same reports as the pages. For the same dates and filters it returns the same values, and the same rules decide what you can see. Sign-ins and activity periods have rules of their own, described in their sections.

Before you start

You need:

A Labelbox API key.
Access to performance data. If you can open a project’s Performance dashboard, you can read that project through the API. Workspace reports need permission to view performance across your organization, as the Monitor does. Sign-ins and activity periods need permission to view all performance across your organization.
For the Python examples, Python SDK version 7.13.0 or later. Member organizations (the member_organization_ids filter and the member_organization_id and member_organization_name fields) and user groups on workspace reports need 7.14.0 or later. Sign-ins (get_sign_in_sessions() and get_sign_in_events()) need 7.15.0 or later.

All endpoints are GET requests under this base URL, authenticated with your API key as a bearer token:

https://api.labelbox.com/api/v1/performance

Quick start

Get the number of labels created per day in a project:

import labelbox as lb

client = lb.Client(api_key="<YOUR_API_KEY>")
project = client.get_project("<PROJECT_ID>")

series = project.get_performance_metric(
    "labels_created", "2026-01-01", "2026-01-31"
)
for bucket in series.buckets:
    print(bucket.start.date(), bucket.value)

curl -H "Authorization: Bearer $LABELBOX_API_KEY" \
  "https://api.labelbox.com/api/v1/performance/projects/$PROJECT_ID/metrics/labels_created?startDate=2026-01-01&endDate=2026-01-31"

The response has one bucket per day:

{
  "projectId": "<PROJECT_ID>",
  "metric": "labels_created",
  "unit": "count",
  "bucketType": "time",
  "buckets": [
    {
      "start": "2026-01-01T00:00:00.000Z",
      "end": "2026-01-02T00:00:00.000Z",
      "value": 412,
      "numerator": null,
      "denominator": null,
      "modes": null
    }
  ],
  "interval": "day",
  "startDate": "2026-01-01",
  "endDate": "2026-01-31",
  "generatedAt": "2026-02-01T09:30:00.000Z"
}

Endpoints

Endpoint	Python SDK	Returns
`GET /metrics`	`client.get_performance_metrics()`	The metrics you can query
`GET /projects/{projectId}/metrics/{metric}`	`project.get_performance_metric()`	One metric for a project, a value per interval
`GET /projects/{projectId}/labelers`	`project.get_labeler_performance()`	Totals for each labeler
`GET /projects/{projectId}/reviewers`	`project.get_reviewer_performance()`	Totals for each reviewer
`GET /projects/{projectId}/download`	`project.get_performance_report_download()`	A link to the report as a file
`GET /workspace/metrics/{metric}`	`client.get_workspace_performance_metric()`	One metric across your workspace
`GET /workspace/labelers`	`client.get_workspace_labeler_performance()`	Totals for each labeler on each project
`GET /workspace/sign-in-sessions`	`client.get_sign_in_sessions()`	Your members’ sign-in sessions, with how and when each ended
`GET /workspace/sign-in-events`	`client.get_sign_in_events()`	Your members’ sign-ins and sign-outs, in the order they happened
`GET /workspace/activity-periods`	Not yet	When your members were active and idle in the editor

Every table is paged. Filters lists which parameters each report takes, Sign-in parameters those of the sign-in endpoints, and Activity parameters those of activity periods. See Paging and Reliability before you build on the API.

Units and dates

Time is in seconds.
Percentages and agreement scores are fractions from 0 to 1. A value of 0.9 means 90%.
Dates are calendar days in UTC, written as 2026-01-31. Reports are bucketed by UTC day. startDate and endDate are the first and last day of the period, both included, and a request can cover at most 366 days, or 31 days for sign-ins and activity periods.
Times, such as generatedAt and when a session started, are in UTC, written as 2026-11-03T08:59:41.120Z.
Wider buckets keep their calendar bounds: a week runs from Monday, a month from the 1st. The first and last bucket of a series can reach beyond your period, but they count only the days inside it. For counts and time totals, a wider bucket is the sum of its days. Averages and percentages are worked out over the whole bucket, so they are not.

In the Python SDK you can pass a date, a datetime, or a string. A datetime with a time zone is converted to its UTC day.

Metrics

List the metrics available to you, with their units and definitions:

for metric in client.get_performance_metrics():
    print(metric.name, metric.unit, metric.description)

curl -H "Authorization: Bearer $LABELBOX_API_KEY" \
  "https://api.labelbox.com/api/v1/performance/metrics"

Throughput

Metric	Unit	What it measures
`done_datarows`	count	Data rows in the Done step of the workflow
`accepted_datarows`	count	Data rows in the Accepted step of the workflow
`labels_created`	count	Labels created in the period
`annotations_created`	count	Annotations created in the period
`approved_reviews`	count	Approve actions, through review tasks in the workflow, on labels created in the period
`rejected_reviews`	count	Reject actions, through review tasks in the workflow, on labels created in the period
`media_duration`	seconds	Total media duration of data rows in the Done step
`media_duration_in_review`	seconds	Total media duration of data rows currently in a Review step
`media_duration_accepted`	seconds	Total media duration of accepted data rows
`total_time`	seconds	Total labeling, review, and rework time spent on labels created in the period
`labeling_time`	seconds	Total time spent in labeling mode while the timer is on
`review_time`	seconds	Total time spent in review mode while the timer is on
`rework_time`	seconds	Total time spent in rework mode while the timer is on

Efficiency

Metric	Unit	What it measures
`avg_time_per_label`	seconds	Total labeling time divided by the number of labels worked on, including skipped and unsaved labels
`avg_review_time`	seconds	Total review time divided by the number of data rows reviewed
`avg_rework_time`	seconds	Total rework time divided by the number of data rows reworked
`aht_labeled_datarows`	seconds	Average handling time per data row with at least one label
`aht_done_datarows`	seconds	Average handling time per data row marked Done
`aht_accepted_datarows`	seconds	Average handling time per data row marked Accepted
`aht_all_labels`	seconds	Average handling time per label created, counting skipped, abandoned, and submitted labels
`aht_submitted_labels`	seconds	Average handling time per submitted label
`aht_done_labels`	seconds	Average handling time per label on done data rows
`aht_accepted_labels`	seconds	Average handling time per label on accepted data rows

Average handling time includes creating, reviewing, and reworking time. The aht_ metrics are listed and can be queried only when average handling time charts are enabled for your organization. Their buckets also carry modes, the handling time split into creating, reviewing, and reworking.

Quality

Metric	Unit	What it measures
`benchmark_percentage`	percentage	Average benchmark agreement score of labels
`benchmark_distribution`	count	Histogram of benchmark agreement scores
`consensus_percentage`	percentage	Average consensus agreement score of labels
`consensus_distribution`	count	Histogram of consensus agreement scores

The two distribution metrics return score ranges instead of time intervals. Their response has "bucketType": "score" and ten buckets, each with rangeStart, rangeEnd, and value, the number of labels whose score falls in that range. The ranges are fractions like the scores themselves: 0 to 0.1, up to 0.9 to 1.

Filters

These parameters narrow a report. Lists are comma-separated in a request, or a Python list in the SDK. The sign-in endpoints take their own: see Sign-in parameters.

Parameter	Python SDK	Applies to	Description
`startDate`, `endDate`	`start_date`, `end_date`	All reports	Required. The period, as UTC days.
`interval`	`interval`	Metrics	Bucket width: `day` (default), `week`, `month`, `quarter`, or `year`.
`userIds`	`user_ids`	All reports	Count only work by these users. Up to 100.
`userGroupIds`	`user_group_ids`	All reports	Count only work by the current members of these user groups. Up to 25 groups, with at most 5,000 members between them. See User groups.
`batchIds`	`batch_ids`	All reports	Count only these batches. Up to 100.
`projectIds`	`project_ids`	Workspace reports	Narrow the report to these projects. Up to 50.
`memberType`	`member_type`	Workspace reports	`internal` for members of your organization, `external` for members of other organizations. See Shared projects and workforce providers.
`ownerOrganizationIds`	`owner_organization_ids`	Workspace reports	Count only projects owned by these organizations. Up to 100.
`memberOrganizationIds`	`member_organization_ids`	Workspace reports	Count only work by members whose account belongs to one of these organizations, such as a workforce provider. Up to 100.
`deletedLabels`	`deleted_labels`	All reports	`include` (default), `exclude`, or `only`.

Filters narrow each other: a report counts only the work that matches every filter you give. With userIds and userGroupIds, for example, only users in both are counted. If nothing matches, every bucket is zero and every table is empty. It is never the unfiltered report. If you can only view your own performance, see Access and privacy.

User groups

A user group filter counts the work of the groups’ current members, whenever that work was done. A member who has left a group is no longer counted with it, and one who has joined is counted for the whole period.

On a project report, the groups are those attached to the project. A group that is empty, is not attached to the project, or that you cannot view matches no work.
On a workspace report, the groups are your organization’s groups. A group of another organization, or one you cannot view, matches no work. You need permission to view user groups across your organization, and a restricted API key must include it.
At most 5,000 members. If the groups you name have more than 5,000 members between them, the request is refused with 400. The count is of the groups’ current members, whatever the dates or other filters, so narrowing the report does not help. Name fewer groups in each request. A single group with more than 5,000 members cannot be used as a filter.

A parameter that an endpoint does not have is refused by name, so a misspelled filter never runs an unfiltered report. A list that is sent must name at least one ID. An empty list is refused with 400 (userIds=), and the Python SDK raises ValueError for one (user_ids=[]). It is not read as “no filter”, which would report on everyone. To leave a filter off, leave the parameter out, or pass None in the SDK.

Labeler and reviewer totals

These are the two tables on the Performance dashboard: one row per member with their totals for the period.

labelers = project.get_labeler_performance(
    "2026-01-01",
    "2026-01-31",
    sort_by="labels_created",
    descending=True,
)
print(labelers.total)
for labeler in labelers:
    print(labeler.email, labeler.labels_created, labeler.avg_time_per_label)

for reviewer in project.get_reviewer_performance("2026-01-01", "2026-01-31"):
    print(reviewer.email, reviewer.labels_reviewed)

curl -H "Authorization: Bearer $LABELBOX_API_KEY" \
  "https://api.labelbox.com/api/v1/performance/projects/$PROJECT_ID/labelers?startDate=2026-01-01&endDate=2026-01-31&sort=labelsCreated&order=desc"

curl -H "Authorization: Bearer $LABELBOX_API_KEY" \
  "https://api.labelbox.com/api/v1/performance/projects/$PROJECT_ID/reviewers?startDate=2026-01-01&endDate=2026-01-31"

Both tables are paged and sortable. See Paging. The response wraps the rows in data and adds page, perPage, and total:

{
  "projectId": "<PROJECT_ID>",
  "data": [
    {
      "userId": "<USER_ID>",
      "projectId": "<PROJECT_ID>",
      "email": "labeler@example.com",
      "memberType": "internal",
      "memberOrganizationId": "<ORGANIZATION_ID>",
      "memberOrganizationName": "Your organization",
      "labelsCreated": 128,
      "labelsSkipped": 3,
      "memberTotalTime": 21640,
      "labelingTimeSubmitted": 19200,
      "labelingTimeSkipped": 240,
      "reviewsReceived": 40,
      "reviewTimeAll": 1800,
      "reworkTimeAll": 600,
      "avgTimePerLabel": 148.4,
      "avgReviewTimeAll": 45,
      "avgReworkTimeAll": 150,
      "avgBenchmarkAgreement": 0.92,
      "avgConsensusAgreement": 0.87,
      "reworkPercentage": 0.03,
      "approvalPercentage": 0.95,
      "avgRating": 4.5,
      "isRemoved": false
    }
  ],
  "page": 1,
  "perPage": 50,
  "total": 37,
  "startDate": "2026-01-01",
  "endDate": "2026-01-31",
  "cachedAt": null,
  "generatedAt": "2026-02-01T09:30:00.000Z"
}

Labeler fields

The Python SDK uses the same names in snake case, such as labels_created.

Field	Description
`userId`, `email`	The member. See Access and privacy for when the email is masked.
`memberType`	`internal` if the member’s account belongs to your organization, `external` if it belongs to another one. `null` if the account no longer exists.
`memberOrganizationId`, `memberOrganizationName`	The organization the member’s account belongs to: yours, or another organization such as a workforce provider. `memberOrganizationName` can be masked; see Access and privacy. Both are `null` if the account no longer exists, and the name is `null` if the organization can no longer be found.
`labelsCreated`	Labels created by the member in the period.
`labelsSkipped`	Labels skipped by the member in the period.
`memberTotalTime`	Total time the member spent in the editor during the period.
`labelingTimeSubmitted`	Labeling time spent by the member on submitted or unsaved labels.
`labelingTimeSkipped`	Labeling time spent by the member on skipped labels.
`reviewsReceived`	Approve and Reject actions, through the workflow review queue, on labels the member created.
`reviewTimeAll`	Total review time spent on labels the member created.
`reworkTimeAll`	Total rework time spent on labels the member created.
`avgTimePerLabel`	Total labeling time divided by the number of labels worked on, including skipped and unsaved labels.
`avgReviewTimeAll`	Total review time divided by the number of labels reviewed, for labels the member created.
`avgReworkTimeAll`	Total rework time divided by the number of labels reworked, for labels the member created.
`reworkPercentage`	Labels the member created that were reworked, divided by the labels they created.
`approvalPercentage`	Labels the member created that received an Approve action, divided by those with any review action.
`avgConsensusAgreement`	Average agreement with other consensus labels, for labels the member created.
`avgBenchmarkAgreement`	Average agreement with benchmark labels, for labels the member created.
`avgRating`	The member’s average rating on the project, or `null` if they have none.
`isRemoved`	`true` when the member is no longer on the project.

Reviewer fields

Field	Description
`userId`, `email`	The member.
`memberType`	`internal` or `external`, as for labelers.
`memberOrganizationId`, `memberOrganizationName`	The organization the member’s account belongs to, as for labelers.
`labelsReviewed`	Labels that had review time from the member in the period.
`labelsReworked`	Labels that had rework time from the member in the period.
`memberTotalTime`	Total time the member spent in the editor during the period.
`reviewTime`	Total review time spent by the member.
`reworkTime`	Total rework time spent by the member.
`avgReviewTime`	Total review time divided by the number of labels reviewed.
`avgReworkTime`	Total rework time divided by the number of labels reworked.
`reworkPercentage`	Labels reviewed by the member that were reworked, divided by the labels they reviewed.
`approvalPercentage`	Labels with an Approve action by the member, divided by labels with any review action by the member.
`isRemoved`	`true` when the member is no longer on the project.

Download the report

Get a link to the project’s performance report as a file. This is the file the Download button on the Performance dashboard gives you.

report = project.get_performance_report_download("2026-01-01", "2026-01-31")
print(report.url)

curl -H "Authorization: Bearer $LABELBOX_API_KEY" \
  "https://api.labelbox.com/api/v1/performance/projects/$PROJECT_ID/download?startDate=2026-01-01&endDate=2026-01-31"

The response has the url and expiresInSeconds. The link works for 24 hours.

Anyone who has the link can open the file until it expires. Treat it like the data it points to.

Workspace reports

Workspace reports are the Monitor’s data. They cover every project your organization owns and every project another organization shares with yours, or only the projects you name in projectIds.

series = client.get_workspace_performance_metric(
    "labels_created", "2026-01-01", "2026-01-31", interval="week"
)

rows = client.get_workspace_labeler_performance(
    "2026-01-01", "2026-01-31", sort_by="labels_created", descending=True
)
print(rows.total)
for row in rows:
    print(row.project_name, row.email, row.member_type, row.labels_created)

curl -H "Authorization: Bearer $LABELBOX_API_KEY" \
  "https://api.labelbox.com/api/v1/performance/workspace/metrics/labels_created?startDate=2026-01-01&endDate=2026-01-31&interval=week"

curl -H "Authorization: Bearer $LABELBOX_API_KEY" \
  "https://api.labelbox.com/api/v1/performance/workspace/labelers?startDate=2026-01-01&endDate=2026-01-31&sort=labelsCreated&order=desc"

workspace/labelers returns one row for each labeler on each project they worked on in the period. A row has the labeler fields, without avgRating, plus:

Field	Description
`projectId`, `projectName`	The project. `projectName` is `null` for a project that can no longer be found.
`projectOrganizationId`, `projectOrganizationName`	The organization that owns the project. It is not yours for a project shared with you. Both are `null` for a project that can no longer be found.
`isProjectDeleted`	`true` when the project has been deleted. Its rows and figures stay in the report.

The table is paged like the project tables. Without sort, rows are ordered by project, then member. Both workspace reports take a user group filter. Use it to report on a team, or on a vendor whose staff have accounts in your own organization:

series = client.get_workspace_performance_metric(
    "labels_created",
    "2026-01-01",
    "2026-01-31",
    interval="week",
    user_group_ids=["<USER_GROUP_ID>"],
)

rows = client.get_workspace_labeler_performance(
    "2026-01-01", "2026-01-31", user_group_ids=["<USER_GROUP_ID>"]
)

curl -H "Authorization: Bearer $LABELBOX_API_KEY" \
  "https://api.labelbox.com/api/v1/performance/workspace/metrics/labels_created?startDate=2026-01-01&endDate=2026-01-31&interval=week&userGroupIds=$USER_GROUP_ID"

curl -H "Authorization: Bearer $LABELBOX_API_KEY" \
  "https://api.labelbox.com/api/v1/performance/workspace/labelers?startDate=2026-01-01&endDate=2026-01-31&userGroupIds=$USER_GROUP_ID"

In the SDK, user_group_ids takes IDs or UserGroup objects; see User groups to find a group. A workspace response repeats projectIds, ownerOrganizationIds, memberOrganizationIds, memberType, and userGroupIds, or null for one you did not use. It does not repeat userIds, batchIds, or deletedLabels. In the SDK, a workspace metric has them as project_ids, owner_organization_ids, member_organization_ids, member_type, and user_group_ids. The result of get_workspace_labeler_performance() does not: it gives the rows, total, and cached_at, and a row’s member_type is that member’s own, not the filter.

Shared projects and workforce providers

A project belongs to one organization and can be shared with another, for example when you add a workforce provider to it. The provider’s members then work in your project, and the project appears in the provider’s workspace as a shared project. The API reflects both sides of that connection. What a workspace report covers. The projects your organization owns, and the projects shared with it. Two fields tell them apart on every row of workspace/labelers:

projectOrganizationId is the organization that owns the project.
memberType is whose member did the work: internal for a member of your organization, external for a member of another organization or an Alignerr member. The Monitor calls external members Workforce members.

Only memberType is told from your side: to a workforce provider its own labelers are internal. Alignerr members are the exception: they are external to everyone, including to Alignerr’s own organization. A third field, memberOrganizationId, is the organization the member’s account belongs to, so it tells one workforce provider from another. Both organization IDs are the same whoever asks: a customer’s project has the customer’s projectOrganizationId in the workforce provider’s report too. Split a report. Use memberType and ownerOrganizationIds on either workspace report. These are the Monitor’s Member Type and Owned by filters. To report on one workforce provider, use memberOrganizationIds with the provider’s organization ID, as found in memberOrganizationId on the rows. If a vendor’s staff have accounts in your own organization, they are internal members of your organization: put them in a user group and filter by userGroupIds instead.

# Labels created each week by your workforce provider's members
external = client.get_workspace_performance_metric(
    "labels_created",
    "2026-01-01",
    "2026-01-31",
    interval="week",
    member_type="external",
)

# The same for your own members
internal = client.get_workspace_performance_metric(
    "labels_created",
    "2026-01-01",
    "2026-01-31",
    interval="week",
    member_type="internal",
)

# As a workforce provider: your members' totals on one customer's projects
rows = client.get_workspace_labeler_performance(
    "2026-01-01",
    "2026-01-31",
    owner_organization_ids=["<CUSTOMER_ORGANIZATION_ID>"],
    member_type="internal",
)

# Labels created each week by one workforce provider's members
provider = client.get_workspace_performance_metric(
    "labels_created",
    "2026-01-01",
    "2026-01-31",
    interval="week",
    member_organization_ids=["<PROVIDER_ORGANIZATION_ID>"],
)

# Labels created by each organization's members, kept by ID: names are
# not unique and can be masked
from collections import Counter

labels, names = Counter(), {}
for row in client.get_workspace_labeler_performance("2026-01-01", "2026-01-31"):
    labels[row.member_organization_id] += row.labels_created
    names[row.member_organization_id] = row.member_organization_name

curl -H "Authorization: Bearer $LABELBOX_API_KEY" \
  "https://api.labelbox.com/api/v1/performance/workspace/metrics/labels_created?startDate=2026-01-01&endDate=2026-01-31&interval=week&memberType=external"

curl -H "Authorization: Bearer $LABELBOX_API_KEY" \
  "https://api.labelbox.com/api/v1/performance/workspace/labelers?startDate=2026-01-01&endDate=2026-01-31&ownerOrganizationIds=$CUSTOMER_ORGANIZATION_ID&memberType=internal"

curl -H "Authorization: Bearer $LABELBOX_API_KEY" \
  "https://api.labelbox.com/api/v1/performance/workspace/metrics/labels_created?startDate=2026-01-01&endDate=2026-01-31&interval=week&memberOrganizationIds=$PROVIDER_ORGANIZATION_ID"

A few rules apply:

A split covers members and projects with activity in the period. As on the Monitor, memberType, memberOrganizationIds, and ownerOrganizationIds select from the members and projects that have rows in the report for your dates and other filters. If none match, every bucket is zero. It is never the unfiltered report.
A split by owner leaves out projects that are gone. A project that can no longer be found has no owner, so ownerOrganizationIds never selects it, and the splits by owner can add up to slightly less than the whole workspace.
A split by owner leaves out projects you cannot report on. Your workspace can include a project you have no role in. A metric split by ownerOrganizationIds does not count it, and lists it in skippedProjectIds so that you know.
A split of a metric needs permission to view everyone’s performance. With projectIds, memberType, memberOrganizationIds, ownerOrganizationIds, and userGroupIds on workspace/metrics need permission to view all performance in every project you name. Otherwise the request returns 403. On workspace/labelers they filter the rows you can already see.
Project reports carry memberType and memberOrganizationId too. The labeler and reviewer tables of a project give each member’s memberType, memberOrganizationId, and memberOrganizationName. Project reports do not take memberOrganizationIds.
Names and emails are masked between a customer and a workforce provider. See Access and privacy. IDs are never masked, so you can always group and filter by userId, projectId, projectOrganizationId, and memberOrganizationId.
User groups belong to one organization. On a project report, the groups are the project’s; a userGroupIds filter on a project shared with you matches no work. On a workspace report, the groups are your own organization’s.

Sign-in sessions show when your organization’s members signed in to Labelbox, and how and when each sign-in ended. Reading them needs permission to view all performance across your organization. The workspace-wide roles Admin, Read-only Admin, Project Lead, and Team Manager have it, and so does a custom role that includes it: see Access and privacy. A session is one sign-in in one browser, or a switch into your workspace from the same person’s user in another workspace. It covers every tab in that browser, the label editor included. Two browsers, or a private window, are two sessions. A session lasts until one of these ends it:

the member signs out;
Labelbox records another end: a new sign-in in the same browser, a switch to another workspace, or the member’s removal;
otherwise, the session reaches its maximum duration. That end is derived when you read the session.

Two endpoints read them:

workspace/sign-in-sessions lists the sessions that started in the period, one row per session.
workspace/sign-in-events lists the sign-ins and sign-outs in the period, in the order they happened. Use it for a timeline, or to keep another system up to date.

Parameter	Python SDK	Applies to	Description
`startDate`, `endDate`	`start_date`, `end_date`	Both	Required. The period, as UTC days, both included, at most 31 days. `endDate` must be before `9999-12-31`.
`userIds`	`user_ids`	Both	Only these members. Up to 100.
`userGroupIds`	`user_group_ids`	Both	Only the current members of these user groups, as on workspace reports. Up to 25 groups, with at most 5,000 members between them. Sessions started in another organization are never listed, even for a member of the groups. With `userIds` too, only members in both are listed.
`status`	`status`	Sessions	`open` for the sessions still open now, `ended` for the sessions that ended, with a recorded or a derived end. Every session when not given.
`types`	`types`	Events	`SIGN_IN`, `SIGN_OUT`, or both, which is the default.
`includeDerived`	`include_derived`	Events	`false` leaves out the derived sign-outs. The default is `true`.
`cursor`, `perPage`	`page_size`	Both	See Paging by cursor.

A list that is sent must name at least one ID, as for the reports. Groups that add no members give no rows, never every member’s.

List sessions

sessions = client.get_sign_in_sessions(
    "2026-11-02", "2026-11-08", user_group_ids=["<USER_GROUP_ID>"]
)
for session in sessions:
    print(
        session.email,
        session.started_at,
        session.end_reason,
        session.end_derived,
        session.duration_seconds,
    )

curl -H "Authorization: Bearer $LABELBOX_API_KEY" \
  "https://api.labelbox.com/api/v1/performance/workspace/sign-in-sessions?startDate=2026-11-02&endDate=2026-11-08&userGroupIds=$USER_GROUP_ID"

The response wraps the sessions in data:

{
  "organizationId": "<ORGANIZATION_ID>",
  "startDate": "2026-11-02",
  "endDate": "2026-11-08",
  "userIds": null,
  "userGroupIds": ["<USER_GROUP_ID>"],
  "status": null,
  "rules": {
    "cookieLifetimeSeconds": 302400,
    "signInTokenLifetimeSeconds": 86400,
    "workspaceTokenLifetimeSeconds": 604800
  },
  "data": [
    {
      "sessionId": "<SESSION_ID>",
      "userId": "<USER_ID>",
      "email": "labeler@example.com",
      "memberDeleted": false,
      "startedAt": "2026-11-03T08:59:41.120Z",
      "startKind": "SIGN_IN",
      "status": "ENDED",
      "endedAt": "2026-11-03T17:31:02.507Z",
      "endReason": "SIGNED_OUT",
      "endDerived": false,
      "expiresAt": "2026-11-06T21:00:41.120Z",
      "durationSeconds": 30681
    },
    {
      "sessionId": "<SESSION_ID>",
      "userId": "<USER_ID>",
      "email": "labeler@example.com",
      "memberDeleted": false,
      "startedAt": "2026-11-04T09:02:10.004Z",
      "startKind": "SIGN_IN",
      "status": "ENDED",
      "endedAt": "2026-11-07T21:03:10.004Z",
      "endReason": "MAX_DURATION_REACHED",
      "endDerived": true,
      "expiresAt": "2026-11-07T21:03:10.004Z",
      "durationSeconds": 302460
    }
  ],
  "nextCursor": null,
  "perPage": 100,
  "generatedAt": "2026-11-09T10:00:00.000Z"
}

Sessions come in the order they started, oldest first. A session that started before startDate is not listed, even if it was still open in the period. To see everything that happened in a period, read the events. The response repeats userIds, userGroupIds, and status, or null for one you did not use. rules gives the lifetimes that expiresAt is worked out from: see Derived ends and the maximum duration. In the Python SDK, the result of get_sign_in_sessions() has neither: it gives only the rows.

Session fields

The Python SDK uses the same names in snake case, such as started_at.

Field	Description
`sessionId`	The session.
`userId`, `email`	The member. `email` is `null` if the user no longer exists or now belongs to another organization.
`memberDeleted`	`true` if the member was deactivated, no longer exists, or now belongs to another organization. A session stays with the organization it started in.
`startedAt`	When the session started.
`startKind`	How it started: see How a session starts.
`status`	`OPEN` or `ENDED`.
`endedAt`	When it ended. For a derived end, `expiresAt`. `null` while the session is open.
`endReason`	Why it ended: see How a session ends. `null` while the session is open.
`endDerived`	`true` when nothing recorded the end and it is `expiresAt`, `false` for a recorded end. `null` while the session is open.
`expiresAt`	The latest the session can end. While it is open it can still move later. Once it has passed, it does not change.
`durationSeconds`	Whole seconds from start to end. `null` while the session is open. It is not time worked.

A session is OPEN while nothing has ended it and its expiresAt is still ahead. It could still be used. It does not mean the member is using Labelbox. The events are a SIGN_IN when a session starts, at its startedAt, and a SIGN_OUT when it ends, at its endedAt, recorded or derived. They are ordered by occurredAt. The period applies to occurredAt, so a session that started before the period can sign out in it.

events = client.get_sign_in_events("2026-11-03", "2026-11-03")
for event in events:
    print(event.occurred_at, event.type, event.email, event.end_reason)
print(events.complete_through)

# Only the sign-outs that were recorded
signed_out = client.get_sign_in_events(
    "2026-11-03", "2026-11-03", types=["SIGN_OUT"], include_derived=False
)

curl -H "Authorization: Bearer $LABELBOX_API_KEY" \
  "https://api.labelbox.com/api/v1/performance/workspace/sign-in-events?startDate=2026-11-03&endDate=2026-11-03"

curl -H "Authorization: Bearer $LABELBOX_API_KEY" \
  "https://api.labelbox.com/api/v1/performance/workspace/sign-in-events?startDate=2026-11-03&endDate=2026-11-03&types=SIGN_OUT&includeDerived=false"

{
  "organizationId": "<ORGANIZATION_ID>",
  "startDate": "2026-11-03",
  "endDate": "2026-11-03",
  "userIds": null,
  "userGroupIds": null,
  "types": ["SIGN_IN", "SIGN_OUT"],
  "includeDerived": true,
  "rules": {
    "cookieLifetimeSeconds": 302400,
    "signInTokenLifetimeSeconds": 86400,
    "workspaceTokenLifetimeSeconds": 604800
  },
  "data": [
    {
      "eventId": "<EVENT_ID>",
      "type": "SIGN_IN",
      "occurredAt": "2026-11-03T08:59:41.120Z",
      "sessionId": "<SESSION_ID>",
      "userId": "<USER_ID>",
      "email": "labeler@example.com",
      "startKind": "SIGN_IN",
      "endReason": null,
      "endDerived": null,
      "sessionStartedAt": "2026-11-03T08:59:41.120Z"
    },
    {
      "eventId": "<EVENT_ID>",
      "type": "SIGN_OUT",
      "occurredAt": "2026-11-03T17:31:02.507Z",
      "sessionId": "<SESSION_ID>",
      "userId": "<USER_ID>",
      "email": "labeler@example.com",
      "startKind": null,
      "endReason": "SIGNED_OUT",
      "endDerived": false,
      "sessionStartedAt": "2026-11-03T08:59:41.120Z"
    }
  ],
  "nextCursor": null,
  "completeThrough": "2026-11-04T00:00:00.000Z",
  "perPage": 100,
  "generatedAt": "2026-11-09T10:00:00.000Z"
}

The feed stops at completeThrough, the earlier of the end of endDate and five minutes ago. Every event before it is listed. Events at or after it are not listed yet: they come in a later read. A derived sign-out is listed once its time is before completeThrough, so the feed never lists a sign-out ahead of time. In the Python SDK, the result of get_sign_in_events() gives only the rows and complete_through, which is None until you have read the events to the end.

Event fields

The Python SDK uses the same names in snake case, such as occurred_at.

Field	Description
`eventId`	The event. It is the same on every read, so you can drop the events you already have.
`type`	`SIGN_IN` or `SIGN_OUT`.
`occurredAt`	When it happened: the session’s start for a sign-in, its end for a sign-out.
`sessionId`, `sessionStartedAt`	The session, and when it started.
`userId`, `email`	The member. `email` is `null` if the user no longer exists or now belongs to another organization.
`startKind`	How the session started. `null` for a sign-out.
`endReason`	Why the session ended. `null` for a sign-in.
`endDerived`	`true` for a derived sign-out, at `expiresAt`, `false` for a recorded one. `null` for a sign-in.

Follow the feed

To keep a copy of the events up to date, read the feed again each time from where the last read stopped:

Ask for the events from the UTC day that holds one hour before the last completeThrough you stored, through today.
Drop the events whose eventId you already have.
Store the new completeThrough for the next read.

A request starts at midnight UTC, so each read repeats between one and 25 hours of events. To drop them, keep the eventId of every event in at least the 25 hours before the completeThrough you stored. The overlap also picks up an event that took unusually long to be recorded. A request covers at most 31 days, so after a longer gap, read the gap in parts.

How a session starts

`startKind`	Meaning
`SIGN_IN`	The member signed in, by any method, including a single sign-on that completed without asking them.
`WORKSPACE_SWITCH`	The member switched into your workspace from their user in another workspace.

How a session ends

`endReason`	Kind	Meaning
`SIGNED_OUT`	Recorded	The member signed out. This includes an idle sign-out by the label editor when the editor is shown inside another Labelbox page: the two cannot be told apart.
`REPLACED`	Recorded	A new sign-in in the same browser replaced the session. The new sign-in need not be this member’s: it can be another account, a sign-up for a new organization, or the start of an impersonation. So a new session of this member need not follow.
`WORKSPACE_SWITCH`	Recorded	The member switched to another workspace. The workspace is not named.
`ACCOUNT_REMOVED`	Recorded	The member was removed from your organization or deactivated.
`REVOKED`	Recorded	The session was ended because the member’s account was merged into another.
`MAX_DURATION_REACHED`	Derived	Nothing ended the session before its `expiresAt`. See Derived ends and the maximum duration.

Derived ends and the maximum duration

When nothing ends a session, it is reported as ended at its expiresAt, with endReason MAX_DURATION_REACHED and endDerived true. This end is derived when you read the session. It is never recorded, and nothing happens at that moment. By then every credential the sign-in issued had lapsed, so the member would have had to sign in again to go on.

A derived end is when the session could last no longer. It is not when the member stopped working, which may have been much earlier. Durations are therefore not time worked. Sessions in two browsers can also overlap, so adding up durations can count the same time twice.

expiresAt is worked out from the lifetimes in rules, given in seconds:

84 hours from sign-in. A session lasts at most the lifetime of the sign-in cookie (cookieLifetimeSeconds, 302,400 seconds), plus a minute, from when the cookie was last set. The sign-in’s own token (signInTokenLifetimeSeconds, 24 hours) lapses before the cookie, so it does not change the end.
Later when extended. Opening a link to the workspace the member is already in, or connecting an application to their account, sets the cookie again and moves an open session’s expiresAt later. A session extended again and again has no fixed maximum.
7 days after a workspace switch, where your organization uses bearer tokens. If your organization signs members in with tokens instead of cookies, a switch into your workspace issues a workspace token (workspaceTokenLifetimeSeconds, 7 days), and the session can last as long as that token.

expiresAt is an upper bound. It assumes the browser kept the cookie: a member who cleared their cookies lost access earlier.

What is not recorded

Sessions record sign-ins and how they ended, not activity. These leave no record:

Closing the tab or the browser, a computer going to sleep, or a lost connection. The session stays open until something else ends it, or until its derived end.
A session expiring. That is the derived end.
The label editor’s idle sign-out when the editor is open in its own tab, as in queue labeling.
A sign-out clicked after the session had expired. The derived end, which came first, stands.
Impersonation. Nothing done while a Labelbox admin impersonates a member is recorded as that member’s.
API keys. Requests made with an API key, such as through the Python SDK, are not sign-ins and start no session.

No IP address, browser, or location is stored. Labelbox began recording sign-ins on 2026-10-15. Earlier sign-ins are not available, and a member who was already signed in then appears from their next sign-in. Sessions are deleted 400 days after they started.

Active and idle periods

Activity periods show when your organization’s members were working in the label editor and when they were idle there, each with a start and an end. Together with sign-in sessions they give you the time to compare with your own shift schedule: time signed in, time active, and time idle. Reading them needs the same permission as sign-ins: to view all performance across your organization.

A member is active (ACTIVE) while the editor’s timer is counting their time.
A member is idle (IDLE) while the editor is open but its timer is paused. The usual reason is no input for five minutes (idleReason INACTIVITY), when the project pauses the timer on inactivity. The editor shows “Inactivity detected” then, and the period ends at the next key press or click. idleReason names other reasons the timer can be paused for.
Time signed in but outside the editor, such as on a project’s overview, is neither. So signed-in time minus active and idle time is time spent elsewhere in Labelbox.

Periods belong to the member, not to a browser tab. While the member is active in one tab, another tab that is idle adds no idle time.

Activity parameters

Parameter	Description
`startDate`, `endDate`	Required. The period, as UTC days, both included, at most 31 days. `endDate` must be before `9999-12-31`.
`userIds`	Only these members. Up to 100.
`userGroupIds`	Only the current members of these user groups, as for sign-ins. Up to 25 groups, with at most 5,000 members between them.
`states`	`ACTIVE`, `IDLE`, or both, which is the default.
`cursor`, `perPage`	See Paging by cursor.

List periods

cURL

curl -H "Authorization: Bearer $LABELBOX_API_KEY" \
  "https://api.labelbox.com/api/v1/performance/workspace/activity-periods?startDate=2026-11-03&endDate=2026-11-03&userGroupIds=$USER_GROUP_ID"

The response wraps the periods in data:

{
  "organizationId": "<ORGANIZATION_ID>",
  "startDate": "2026-11-03",
  "endDate": "2026-11-03",
  "userIds": null,
  "userGroupIds": ["<USER_GROUP_ID>"],
  "states": ["ACTIVE", "IDLE"],
  "rules": {
    "editorInactivitySeconds": 300,
    "signalLostSeconds": 180,
    "maxPeriodSeconds": 43200
  },
  "data": [
    {
      "periodId": "<PERIOD_ID>",
      "userId": "<USER_ID>",
      "email": "labeler@example.com",
      "memberDeleted": false,
      "state": "ACTIVE",
      "idleReason": null,
      "status": "ENDED",
      "startedAt": "2026-11-03T09:01:12.402Z",
      "endedAt": "2026-11-03T10:47:30.118Z",
      "endReason": "STATE_CHANGED",
      "durationSeconds": 6377
    },
    {
      "periodId": "<PERIOD_ID>",
      "userId": "<USER_ID>",
      "email": "labeler@example.com",
      "memberDeleted": false,
      "state": "IDLE",
      "idleReason": "INACTIVITY",
      "status": "ENDED",
      "startedAt": "2026-11-03T10:47:30.118Z",
      "endedAt": "2026-11-03T11:02:05.950Z",
      "endReason": "STATE_CHANGED",
      "durationSeconds": 875
    }
  ],
  "nextCursor": null,
  "perPage": 100,
  "generatedAt": "2026-11-04T08:00:00.000Z"
}

Every period that overlaps the period you ask for is listed, oldest start first, including one that started the day before and ran into it. To add up a day, clip each period to the day. An open period has status OPEN and endedAt null.

Period fields

Field	Description
`periodId`	The period.
`userId`, `email`	The member. `email` is `null` if the user no longer exists or now belongs to another organization.
`memberDeleted`	`true` if the member was deactivated, no longer exists, or now belongs to another organization.
`state`	`ACTIVE` or `IDLE`.
`idleReason`	Why the timer was paused. `null` for an active period.
`status`	`OPEN` while the period lasts, `ENDED` once it has ended.
`startedAt`, `endedAt`	When the period started and ended. `endedAt` is `null` while it is open.
`endReason`	How it ended. `null` while it is open.
`durationSeconds`	Whole seconds from start to end. `null` while it is open.

Why a period is idle

`idleReason`	Meaning
`INACTIVITY`	No input in the editor for `rules.editorInactivitySeconds` (five minutes), or no activity seen by the time tracker the project requires.
`POSSIBLE_INACTIVITY`	The time tracker the project requires saw too little activity to be sure.
`EXTERNAL_TIMER_NOT_RUNNING`	The time tracker the project requires was not running.
`TASK_HELD_BY_AUTOMATION`	The task moved to an automated step of the workflow.
`TIMER_PAUSED`	The timer was paused for none of those reasons: the member paused it, or the task reached its time limit.

For idle time in the strict sense, filter on INACTIVITY (and POSSIBLE_INACTIVITY where a time tracker is required).

How a period ends

`endReason`	Meaning
`STATE_CHANGED`	The next period started: the member went idle, came back, or paused the timer.
`SIGNAL_LOST`	The editor stopped sending anything for `rules.signalLostSeconds`: the tab was closed, the computer went to sleep, or the connection was lost. The period ends at the editor’s last signal, not three minutes later. Until then it shows as open, for up to about four minutes.
`MAX_DURATION_REACHED`	The period ran for `rules.maxPeriodSeconds` (12 hours) and the next one started.
`WORKSPACE_CHANGED`	The member switched to another workspace.

What is recorded

Periods are recorded in the organization the member works in. A workforce provider’s members, or Alignerr accounts, working on your projects are recorded in their own organization, not yours. Nothing done while a Labelbox admin impersonates a member is recorded. Recording is being turned on organization by organization. Earlier time is not available, and periods are deleted 400 days after they started.

Paging

The three tables (projects/{projectId}/labelers, projects/{projectId}/reviewers, and workspace/labelers) are paged by page number. In the Python SDK, iterating a table fetches one page at a time, and total gives the number of rows without reading them all:

Python

rows = client.get_workspace_labeler_performance(
    "2026-01-01", "2026-01-31", page_size=100
)
print(rows.total)
for row in rows:  # fetches page after page as you go
    ...

The sign-in endpoints and activity periods are paged by cursor instead, with no page and no total: see Paging by cursor. In a request, use these parameters:

Parameter	Description
`page`	Page number, starting at 1. Written in digits only.
`perPage`	Rows per page, up to 100. The default is 50. In the SDK, `page_size`.
`sort`	A field of the row, such as `labelsCreated`. In the SDK, `sort_by="labels_created"`.
`order`	`asc` (default) or `desc`. In the SDK, `descending=True`.
`useCache`	`false` reads the report again instead of using rows read in the last few minutes. In the SDK, `use_cache=False`. Not available on reviewers.

Every table response has page, perPage, and total, the number of rows across all pages. Request pages until you have total rows. A page past the end returns an empty data.

cURL

curl -H "Authorization: Bearer $LABELBOX_API_KEY" \
  "https://api.labelbox.com/api/v1/performance/workspace/labelers?startDate=2026-01-01&endDate=2026-01-31&perPage=100&page=2"

Keep these in mind when you read a whole table:

Leave the cache on. The pages of workspace/labelers are cut from one reading of the report, kept for five minutes from when it was taken, so they agree with each other while it lasts and the rows are in a fixed order. cachedAt says when that reading was taken. With useCache=false every page reads the report again, and so does a very large table, which is not kept.
A user group filter is applied to each page. On every table, who is in the groups is worked out again for each page. If someone joins or leaves one of the groups while you read the table, a row can be missed or repeated. If total changes from one page to the next, start again from page 1. The Python SDK checks this for you: from 7.14.0, iterating raises PerformanceTableChangedError when a page’s total differs from the first page’s. A change that leaves total as it was cannot be seen this way, such as a member joining a group as another with the same number of rows leaves.
Sorting. Every table sorts by the figures in its rows, such as labelsCreated or avgTimePerLabel, except avgRating. Rows cannot be sorted by member organization. Without sort, the project tables come ordered by email, as on the Performance dashboard, and rows that tie under a sort are in that order too. A masked email keeps the place of the real one. workspace/labelers comes ordered by project, then member.
Metrics are not paged. A metric returns at most one bucket per day of the period, and the period is limited to 366 days.

Paging by cursor

workspace/sign-in-sessions, workspace/sign-in-events, and workspace/activity-periods are paged by cursor, not by page number. In the Python SDK, iterating fetches one page at a time, as for the tables:

Python

for session in client.get_sign_in_sessions("2026-11-02", "2026-11-08"):
    ...  # fetches page after page as you go

In a request, use these parameters:

Parameter	Description
`cursor`	Where the previous page ended: its `nextCursor`, sent as it was. Leave it out for the first page.
`perPage`	Rows per page, up to 100. The default is 100. In the SDK, `page_size`.

Every response has nextCursor, or null on the last page. Request pages, with the same other parameters, until nextCursor is null. There is no page, no total, and no sort: sessions and activity periods come in the order they started, and events in the order they happened. A cursor is not meant to be read or built, and a value the endpoint did not return is refused with 400.

cURL

curl -H "Authorization: Bearer $LABELBOX_API_KEY" \
  "https://api.labelbox.com/api/v1/performance/workspace/sign-in-sessions?startDate=2026-11-02&endDate=2026-11-08&cursor=$NEXT_CURSOR"

A user group filter is applied to each page here too. A member who joins or leaves one of the groups while you read is listed only on the pages read while they were in it.

Access and privacy

The API shows you what the pages show you.

Your own performance only. If you can only view your own performance on a project, every project report returns only your data, whatever userIds or userGroupIds you pass. The same goes for a workspace report when you name such a project in projectIds: it counts only your own work, whatever userIds you pass. workspace/metrics then refuses userGroupIds, memberType, memberOrganizationIds, and ownerOrganizationIds with 403.
Workspace reports. Without projectIds, you need permission to view performance across your organization. With projectIds, you need performance access to each project you name.
Projects you cannot see. A project you have no performance access to returns 404, the same as a project that does not exist.
Splitting by member type, organization, or user group. On workspace/metrics, memberType, memberOrganizationIds, ownerOrganizationIds, and userGroupIds need permission to view all performance in every project you name in projectIds. A project found through its owner that you cannot report on is left out and listed in skippedProjectIds.
User groups. A userGroupIds filter on a workspace report needs permission to view user groups across your organization. Without it, the groups match no one: the metric is zero and the table is empty, never the unfiltered report. If you can only view your own performance, workspace/labelers returns your own rows, and with userGroupIds only if you are in one of the groups.
Masked emails. The email of a member you may not identify is replaced with a masked value, as on the pages. For example, a workforce provider’s members appear masked to the project’s owner, and the owner’s members appear masked to the provider.
Masked project and organization names. A workforce provider does not see the names of the projects shared with it or of the organizations that own them. In workspace/labelers, projectName and projectOrganizationName are replaced with masked values for those projects. memberOrganizationName, in all three tables, is masked by the same rules, as org.name.<ID>: a workforce provider sees its customers’ organization names masked, and a customer sees the names of its workforce providers. The IDs are unchanged.
Sign-ins. The sign-in endpoints need permission to view all performance across your organization. Performance access to projects does not count, and neither does permission to view your own performance: a member cannot read their own sign-ins, and gets 403. Only sessions started in your organization are listed. Accounts of other organizations, such as a workforce provider’s members or Alignerr accounts, have none here, even when they work on your projects or are in your user groups. A member who has since moved to another organization keeps the sessions they started in yours, with email null and memberDeleted true.
Activity periods. The same as sign-ins: they need permission to view all performance across your organization, a member cannot read their own, and only periods recorded in your organization are listed.
Restricted API keys. A key created with a limited set of permissions needs a performance permission, and is limited to the ones it has. A key that only has permission to view your own performance returns only your own. For sign-ins and activity periods, such a key needs permission to view all performance, or it is refused with 403.

Data freshness

The API reads the same data as the Performance dashboard and the Monitor, so it is never more current than those pages. That data is rebuilt periodically, not continuously: the current day’s figures can trail real activity by anything from a quarter of an hour to over an hour. A response served from the cache can be up to five minutes older again. generatedAt is when the response was produced. cachedAt, on the labeler tables, is set when the rows came from a result computed in the last few minutes. Neither tells you how recent the underlying activity data is, and no response carries an as-of time for it. Two things follow for the current day:

Today’s bucket keeps growing. Read settled days for totals you will not revisit.
Charts and tables do not refresh together. For settled days a metric and the labeler table normally add up to the same total. For the current day they can differ until both have caught up.

Sign-ins and activity periods are not part of that data. They are read as they are recorded, and the events feed lists everything up to five minutes ago: see Sign-in and sign-out events.

Limits

Limit	Value
Period	366 days per request, or 31 days for sign-ins and activity periods
`userIds`, `batchIds`	100 IDs each
`userGroupIds`	25 groups, with at most 5,000 members between them
`projectIds`	50 projects
`ownerOrganizationIds`, `memberOrganizationIds`	100 organizations each
`perPage`	100 rows

Requests count toward your API rate limit, like the rest of the Labelbox API.

Reliability

Requests are safe to repeat. Every endpoint is a GET and changes nothing, so you can retry any request.
Retry 5xx responses and timeouts with a growing delay between attempts. The Python SDK does this for you, for up to four minutes, and tries once more after a request that timed out. When it stops retrying, it raises the error that kept happening.
Do not retry 4xx responses without changing the request. For 429, wait before sending more.
Allow for long requests. Reports are computed when you ask, and a long period over a large workspace can take a while. The Python SDK waits up to 120 seconds for a response.
Prefer fewer, wider requests. One request for a month at interval=day costs less than a request for each day. To read every member’s totals for a project as a file, use Download the report.
Expect new fields. Responses can gain fields over time. Ignore the ones you do not know. The Python SDK does.

Errors

Status	Meaning	Python SDK exception
`400`	A parameter is invalid, the user groups named have more than 5,000 members between them, or a `cursor` is not one the endpoint returned. The response lists each parameter in `details`.	`InvalidQueryError`
`401`	The API key is missing or invalid.	`AuthenticationError`
`403`	Your role or API key does not include the permission, or you named a project in a split by member type, organization, or user group where you cannot view everyone’s performance. Sign-ins and activity periods need permission to view all performance across your organization.	`AuthorizationError`
`404`	The metric does not exist, or the project does not exist or is not visible to you.	`ResourceNotFoundError`
`429`	You have made too many requests.	`ApiLimitError`
`500`	The report could not be produced. Try again.	`InternalServerError`
`503`	Performance reports are under maintenance. Try again later. The sign-in endpoints and activity periods are not affected.	`InternalServerError`

The Python SDK raises TimeoutError when a request gets no response in time, and NetworkError when it cannot connect. All of these exceptions are in lbox.exceptions. It raises Python’s ValueError, before sending anything, for a filter given as an empty list. A 400 response names each parameter that was refused:

{
  "statusCode": 400,
  "error": "Bad Request",
  "message": "Invalid query parameters",
  "details": [
    { "parameter": "endDate", "message": "must not be before startDate" }
  ]
}

​Before you start

​Quick start

​Endpoints

​Units and dates

​Metrics

​Throughput

​Efficiency

​Quality

​Filters

​User groups

​Labeler and reviewer totals

​Labeler fields

​Reviewer fields

​Download the report

​Workspace reports

​Shared projects and workforce providers

​Sign-in sessions

​Sign-in parameters

​List sessions

​Session fields

​Sign-in and sign-out events

​Event fields

​Follow the feed

​How a session starts

​How a session ends

​Derived ends and the maximum duration

​What is not recorded

​Active and idle periods

​Activity parameters

​List periods

​Period fields

​Why a period is idle

​How a period ends

​What is recorded

​Paging

​Paging by cursor

​Access and privacy

​Data freshness

​Limits

​Reliability

​Errors

Before you start

Quick start

Endpoints

Units and dates

Metrics

Throughput

Efficiency

Quality

Filters

User groups

Labeler and reviewer totals

Labeler fields

Reviewer fields

Download the report

Workspace reports

Shared projects and workforce providers

Sign-in sessions

Sign-in parameters

List sessions

Session fields

Sign-in and sign-out events

Event fields

Follow the feed

How a session starts

How a session ends

Derived ends and the maximum duration

What is not recorded

Active and idle periods

Activity parameters

List periods

Period fields

Why a period is idle

How a period ends

What is recorded

Paging

Paging by cursor

Access and privacy

Data freshness

Limits

Reliability

Errors