Overview & data types
We chose to use GraphQL to structure our API because it provides more flexibility than REST. Here are some advantages GraphQL offers:
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.
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.
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,
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.
createLabel example below is a
Mutation field. To see an implementation sample for
createLabel, see Import Label.
Fields allow you to perform specialized operations within the
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. See our API explorer for a complete list.
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.
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.
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.
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.
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.