Overview & data types

Updated 1 month ago by Alex Cota

GraphQL introduction

We chose to use GraphQL to structure our API because it provides more flexibility than REST. Here are some advantages GraphQL offers:

Strongly-typed schema

Both the request query and the response are strongly typed. You will know your query is valid because the schema will not allow improperly written schemas.

Hierarchical structure

Each GraphQL query and response takes the shape of a hierarchical set of fields. This makes the queries easy to create and the responses intuitive to read.

Minimal query payloads

Unlike in a REST API, a GraphQL response will include only the data you specify in your query.

Strong tooling

Tools like our API explorer allow you to explore the API schema and run queries in your browser.

Root operation types

Our GraphQL API makes use of two operation types, Query and Mutation. These are special because they provide the entry point for every GraphQL query. We encourage you to experiment with these operation types in our API explorer.

Fields, arguments & object types

Fields, arguments, and object types are used to construct the schema. The Query fields perform read-only operations and the Mutation fields perform writes.

The createLabel example below is a Mutation field. To see an implementation sample for createLabel, see Import labels.

Fields allow you to perform specialized operations within the Query and Mutation root operation types. The createLabel field in the example above requires an argument and targets the Label object type.

Arguments are defined by name and type and serve a variety of purposes. Each field can have zero or more arguments. In the example above, the data: LabelCreateInput argument is required as specified by the (!) symbol.

Object types (Data types) are the entities in the database that receive the action performed by the field. For the createLabel field, the Label object type is required as specified by the (!) symbol.

Labelbox Core Data Types

These are the object types that get used and referenced the most.


An individual person involved in the data annotation process, including review and/or project management. Users can have various permission levels.


The data type that serves as the container for Users.

Asset Metadata

A collection of supplementary information associated with an asset. Click here to learn more.


A single annotation on a given asset. For example, 1 bounding box + 1 instance of image classification = 2 features.


A collection of features on a single asset. A Label represents an assessment on a Data Row. Click here to learn how to import Labels.


Indicates the quality of a given Label as indicated by a User.

Data Row

The data type that individual assets are assigned to, serving as the internal Labelbox representation of an asset. Click here to learn how to import Data Rows.


A collection of Data Rows. Each asset is assigned to a Data Row. Datasets can span multiple Projects.


The workspace for the data annotation workflow. It is where the labeling, quality assurance, labeling performance monitoring, and progress overviews are contained.

Labeling Frontend

The Labelbox HTML / JavaScript labeling interface for data annotation.

Prediction (Model-assisted label)

A predicted annotation created by a machine-learning model. Predictions are often used as a starting point to decrease human labeling time. Click here to learn more.

Prediction Model

Represents the machine-learning model that generates Predictions. Click here to learn how to import a Prediction Model.


A server-side operation.


An entity representing a subscription to a type of event on the Labelbox platform. Whenever an event of the subscribed-to type occurs, the webhook's endpoint receives a notification. Webhooks can be organization-wide or project-based. Click here to learn more.

Was this page helpful?