Examples Using Rize's GraphQL API

Examples have been provided below to help you get started using Rize's GraphQL API.

The comprehensive schema documentation for Rize's API can be viewed from the GraphQL Playground at https://api.rize.io/api/v1/graphiql by clicking the "Show Documentation Explorer" icon in the top left.

Example Query

This is an example using the Project query in the Rize GraphQL API.

Project Query

curl -X POST https://api.rize.io/api/v1/graphql \
-H "Content-Type: application/json" \
-H "Authorization: Bearer YOUR_API_KEY" \
-d '{
  "query": "query Project($id: ID!) { project(id: $id) { id name } }",
  "variables": {
    "id": "124119"
  }
}'

Successful Response

{"data":{"project":{"id":"124119","name":"Your Project Name"}}}

Error Response

{"errors":[{"message":"Variable $id of type ID! was provided invalid value","locations":[{"line":1,"column":15}],"extensions":{"value":null,"problems":[{"path":[],"explanation":"Expected value to not be null"}]}}]}

Example Mutation

This is an example using the CreateProject mutation in the Rize GraphQL API.

CreateProject Mutation

curl -X POST https://api.rize.io/api/v1/graphql \
-H "Content-Type: application/json" \
-H "Authorization: Bearer YOUR_API_KEY" \
-d '{
  "query": "mutation CreateProject($name: String!) { createProject(input: { args: { name: $name } }) { project { id name } } }",
  "variables": {
    "name": "Your Project Name"
  }
}'

Successful Response

{"data":{"createProject":{"project":{"id":"124112319","name":"Your Project Name"}}}}

Error Response

{"data":{"createProject":null},"errors":[{"message":"You must be signed in to access mutation CreateProject","locations":[{"line":1,"column":42}],"path":["createProject"],"extensions":{"code":"AUTHENTICATION_ERROR"}}]}

Titles and departments

Catalog reads require active workspace membership. Pass the workspace ID as workspaceId. Both queries return active records, support case-insensitive search, and use cursor pagination with 25 results by default and a maximum of 50.

query Catalogs($workspaceId: ID!, $search: String, $after: String) {
  titles(workspaceId: $workspaceId, search: $search, first: 25, after: $after) {
    nodes { id name department { id name } }
    pageInfo { endCursor hasNextPage }
  }
  departments(workspaceId: $workspaceId, search: $search, first: 25) {
    nodes { id name }
    pageInfo { endCursor hasNextPage }
  }
}

Each connection has its own cursor. The example uses after for titles; paginate departments separately with that connection's endCursor.

Workspace admins can create departments and titles with separate mutations. Run department creation first, then use its returned ID when creating a title. Pass departmentId: null to guarantee an unassigned title. Omitting departmentId leaves a new title unassigned, but preserves the previous department when restoring an archived title.

mutation NewDepartment($workspaceId: ID!, $name: String!) {
  createDepartment(input: { workspaceId: $workspaceId, name: $name }) {
    department { id name }
    errors { path message }
  }
}

mutation NewTitle($workspaceId: ID!, $name: String!, $departmentId: ID) {
  createTitle(input: { workspaceId: $workspaceId, name: $name, departmentId: $departmentId }) {
    title { id name department { id name } }
    errors { path message }
  }
}

Use updateTitle and updateDepartment for changes. For example, this mutation renames a title:

mutation RenameTitle($workspaceId: ID!, $id: ID!, $name: String!) {
  updateTitle(input: { workspaceId: $workspaceId, id: $id, name: $name }) {
    title { id name }
    errors { path message }
  }
}

Both update mutations accept archived: true to archive or archived: false to restore. updateTitle also accepts departmentId: omit it to preserve the current department, or pass null to clear it. Referenced records must belong to the same workspace, and a newly assigned department must be active.

Creating a name that matches an archived record restores that record rather than duplicating it. Matching ignores capitalization and surrounding spaces. Active duplicate names fail validation. Model validation failures return a null record and structured payload errors; authorization and unavailable-record failures can return top-level GraphQL errors. Check both when handling a response.

Archiving clears assignments asynchronously. Restoring a record does not restore assignments already cleared. See archive behavior before using these mutations.

For member metadata, request title, titleId, and department { id name } from workspaceMembers or teamMembers. The public API has no batch catalog mutations.