> For the complete documentation index, see [llms.txt](https://navixy.com/docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://navixy.com/docs/navixy-graphql-api/products/console/api-reference.md). # Console API reference How the Console reference is organized: one page each for the organizations and the workspaces a caller can reach and for the products of a workspace, and how Console's connections paginate. The Console API reference documents the operations and types that Navixy GraphQL API exposes from Navixy Console: the organizations and workspaces the caller can reach, and the products a workspace has. Each page covers its queries and mutations, its object and input types, and its enums, with a field table for every type. The reference states what each operation and field is. For the GraphQL fundamentals behind the notation, see [GraphQL basics](/docs/navixy-graphql-api/graphql-basics.md), including the [type syntax](/docs/navixy-graphql-api/graphql-basics.md#type-syntax) that the field tables use. ## Where the operations live All Console queries are nested under the `console` field of the `Query` type, and the Console mutations under the `console` field of the `Mutation` type. Every response has the same shape under `data.console`. A `console { ... }` mutation block runs one mutation at a time. Navixy Console owns organizations, workspaces, and the products a workspace runs. This API relays what Console reports for the caller: the values of `status`, `orgType`, `roles`, `operationType`, the operation `status`, and a member's `principalType`, `principalSubtype`, `rolePreset`, and `status` are Console's own vocabulary, returned as plain strings. The `roles` of an organization record your membership, such as `owner` or `member`, and don't decide what you may do: that comes from the roles set up in Navixy Console. The `accessibleWorkspaces` query leaves out any workspace whose ID isn't a workspace ID of this deployment. Enabling or disabling a product is asynchronous. The mutation answers as soon as Console accepts the request, with the operation that Console tracks for it. Read the outcome with `workspaceOperation` or `workspaceProducts`. A request that Console refuses comes back as an error that names Console: see [Refusals relayed from Navixy Console](/docs/navixy-graphql-api/error-handling.md#refusals-relayed-from-navixy-console). ## Pages
PageCovers
OrganizationsConsoleOrganization, with the caller's membership preset in it, and the accessibleOrganizations query with its connection and edge types.
WorkspacesConsoleWorkspace, with the organization and the zone it belongs to, and the accessibleWorkspaces query with its connection and edge types.
MembersConsoleMember, a person or agent of your organization with what you may do to them, and the members query with its connection and edge types.
ProductsThe products a workspace may or does have enabled (ConsoleWorkspaceProduct), Console's product catalog (ConsoleProductCatalogEntry), and the operation Console tracks for a toggle (ConsoleWorkspaceOperation), with the workspaceProducts, productCatalog, and workspaceOperation queries and the workspaceProductEnable and workspaceProductDisable mutations.
## How these connections paginate The Console connections follow Console's own pagination, which differs from the [pagination](/docs/navixy-graphql-api/pagination.md) the other products use: * Backward paging needs a cursor. `first` and `after` page forward. `last` pages backward only together with `before`, and `before` is only valid together with `last`. `first` doesn't combine with `last` or `before`, and `last` doesn't combine with `after`. The API checks these rules before it calls Console and answers `VALIDATION_ERROR` when they are broken. * Every edge carries its own cursor. `pageInfo.startCursor` and `pageInfo.endCursor` are the first and the last cursor of the page, and they are null only when Console's own page had no items. A page whose rows the API left out still carries them. * `total` is exact on `accessibleOrganizations` and approximate on `accessibleWorkspaces`, because Console counts every workspace, including the ones this API leaves out. * A cursor is valid only for the query that returned it. Passing it to the other query returns an unrelated page, not an error. * `accessibleWorkspaces` can return fewer items than `first`, or none, while `pageInfo.hasNextPage` is still `true`: it leaves out any workspace whose ID isn't a workspace ID of this deployment without adjusting the page size. Keep paging past a short or empty page. `accessibleOrganizations` doesn't leave out rows this way. * `members` is paged by the API, not by Console, because Console answers the whole member list at once. The page is ordered by `actorId`, the cursor of each edge is the actor ID, and `total` is exact. A cursor that isn't an actor ID returns `VALIDATION_ERROR`. * The default page size is 50, and `first` and `last` accept 1 to 100 on every query. The default of 20 on the general [Pagination](/docs/navixy-graphql-api/pagination.md) page doesn't apply here. A short page is what the last rule looks like. This request asks for 50 workspaces after a cursor: ```graphql query NextWorkspaces { console { accessibleWorkspaces( first: 50 after: "d3M6MDE5YTZiMmYtNzkzZS04MDdiLTgwMDEtNTc1MzUwNDMwMDAy" ) { nodes { id workspaceName } pageInfo { hasNextPage endCursor } } } } ``` The response has no nodes and still has a next page: ```json { "data": { "console": { "accessibleWorkspaces": { "nodes": [], "pageInfo": { "hasNextPage": true, "endCursor": "d3M6MDE5YTZiMmYtNzkzZS04MDdiLTgwMDEtNTc1MzUwNDMwMDM0" } } } } } ``` Send `endCursor` as `after` again. Stop only when `hasNextPage` is `false`. ## Identifiers `ConsoleOrganization.id` is an `ID` that Console issues, the same value as `Workspace.organizationId` in Business Data Repository. `ConsoleOrganization` is a `Node`. `node(id:)` and `nodes(ids:)` return an organization only when it's one of your own organizations, the organizations that `accessibleOrganizations` lists, and return `null` for any other organization ID. When Console doesn't respond, the organization is `null` and an error names its path. See [When Console doesn't respond](/docs/navixy-graphql-api/products/console/errors.md#when-console-doesnt-respond). `ConsoleWorkspace.id` is an `ID`, the same value as `Workspace.id` in Business Data Repository. `ConsoleWorkspace` isn't a `Node`: for a workspace ID, `node(id:)` returns the Business Data Repository `Workspace` of the workspace that your token names. `ConsoleMember.actorId` is a `UUID` of Console's own: the `actorId` that the IAM role assignment operations take. Product IDs are Billing's. `ConsoleWorkspaceProduct.productId`, `ConsoleProductCatalogEntry.id`, and the `productId` that `workspaceProductDisable` takes are the same values as `BillingProductDomain.id`, and `coveredBySubscriptionId` is a Billing subscription ID. An operation ID is an `ID` that Console issues: `ConsoleWorkspaceOperation.id`, `ConsoleWorkspaceOperationReceipt.id`, and the `id` that `workspaceOperation` takes. No type of the API is an operation, so `node(id:)` returns `null` for an operation ID. The `organizationId` of an operation is the organization ID described above. The IDs of the user or agent behind an operation, `actorUserId` and `actorAgentId`, are `UUID` values of Console's own. The API checks the kind of every organization ID and operation ID that you send. The `organizationId` of `accessibleWorkspaces` must be an organization ID, and the `id` of `workspaceOperation` must be an operation ID. Any other value returns `VALIDATION_ERROR`: see [Errors before Console is called](/docs/navixy-graphql-api/products/console/errors.md#errors-before-console-is-called). ## Shared types The interfaces and pagination types that Console shares with the other products are on the [Common resources](/docs/navixy-graphql-api/core-api-reference/common.md) page. The [Core API reference](/docs/navixy-graphql-api/core-api-reference.md) indexes the reference pages of every product. ## Other ways to explore the API * [Public GraphQL schema](/docs/navixy-graphql-api/developer-resources/public-graphql-schema.md): The full type system split into several files. * [Introspection](/docs/navixy-graphql-api/graphql-basics.md#introspection): Explore the schema from your own GraphQL client. ## See also * [Authentication](/docs/navixy-graphql-api/authentication.md): Learn how the access token names the workspace that every request acts in. * [Error handling](/docs/navixy-graphql-api/error-handling.md): Understand error structure, codes, and common error scenarios. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://navixy.com/docs/navixy-graphql-api/products/console/api-reference.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.