> 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/billing/api-reference.md).

# Billing API reference

How the Billing reference is organized: one page per topic for plans, subscriptions, balances, submissions, and invoices.

The Billing API reference documents every public operation and type of Billing, grouped into one page per topic. 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 Billing queries and mutations are nested under the `billing` field of the `Query` and `Mutation` types, and every response has the same shape under `data.billing`.

Every operation is one of the [my\* operations](/docs/navixy-graphql-api/products/billing.md#purpose-and-capabilities), named with the prefix `my`: it acts in the workspace named by your access token and takes no workspace argument. Navixy products report usage to Billing outside this API, and the submission queries list what they reported for your workspace.

For a workspace token, `node(id:)` returns `null` for billing types other than the 2 submission types, and for a submission of another workspace. Read them through the queries on these pages.

## Pages

<table><thead><tr><th width="186">Page</th><th>Covers</th></tr></thead><tbody><tr><td><a href="/docs/navixy-graphql-api/products/billing/api-reference/plan.md">Plans</a></td><td>The plans and branches your workspace may subscribe to (<code>BillingAvailablePlan</code>, <code>BillingAvailablePlanItem</code>), the <code>myAvailablePlans</code> query that lists them with the subscription you already have on each, and the catalog and pricing vocabulary a plan is built from: <code>BillingProductDomain</code>, <code>BillingMetric</code>, <code>BillingPricingModel</code>, <code>BillingAggregationFunction</code>, <code>BillingUsagePricing</code>, and <code>BillingUsagePricingTier</code>.</td></tr><tr><td><a href="/docs/navixy-graphql-api/products/billing/api-reference/subscription.md">Subscriptions</a></td><td>The <code>mySubscribe</code> mutation and the <code>mySubscriptions</code> query, with <code>BillingWorkspaceSubscription</code>, its filter and order inputs, and its pagination types.</td></tr><tr><td><a href="/docs/navixy-graphql-api/products/billing/api-reference/balance.md">Balances</a></td><td>Your workspace's prepaid balance (<code>BillingBalance</code>), the statement entries that changed it (<code>BillingBalanceEntry</code>), and the <code>myBalance</code> and <code>myBalanceEntries</code> queries.</td></tr><tr><td><a href="/docs/navixy-graphql-api/products/billing/api-reference/submission.md">Submissions</a></td><td>The usage-metric and invoice-line-item submissions reported for your workspace (<code>BillingUsageMetricSubmission</code>, <code>BillingInvoiceLineItemSubmission</code>), and the <code>myUsageMetricSubmissions</code> and <code>myInvoiceLineItemSubmissions</code> queries that list them, with their filter and order inputs.</td></tr><tr><td><a href="/docs/navixy-graphql-api/products/billing/api-reference/invoice.md">Invoices</a></td><td>Your workspace's invoices (<code>BillingWorkspaceInvoice</code>) with their lines (<code>BillingWorkspaceInvoiceLineItem</code>), and the <code>myInvoice</code> and <code>myInvoices</code> queries that read them, with their filter and order inputs.</td></tr></tbody></table>

## Shared types

The scalars, interfaces, and pagination types that Billing shares with the other products are on the [Common resources](/docs/navixy-graphql-api/core-api-reference/common.md) page. Billing also uses the `Money` value type and the `Currency` scalar from that page. The usage prices of a plan (`BillingUsagePricing.price` and the `price` of a tier) are `Long` values in minor currency units; the period fee, balances, and invoice line items use `Money`. The [Core API reference](/docs/navixy-graphql-api/core-api-reference.md) indexes the reference pages of every product.

## How the reference pages are structured

Every page follows the same order: queries, then mutations, then the page's objects, inputs, and enums, with pagination types in a section of their own at the end. Field tables use the GraphQL type notation, where `!` marks a value that is never null and `[...]` marks a list: see [Type syntax](/docs/navixy-graphql-api/graphql-basics.md#type-syntax).

## 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

* [Pagination](/docs/navixy-graphql-api/pagination.md): Learn how the connection types on these pages page through results.
* [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/billing/api-reference.md?ask=<question>&goal=<user_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.