Skip to main content
Retrieve the billing arrangement, configured pricing, balance or unbilled charges, payment method, and billing history for the workspace associated with your API key.
This endpoint is read-only. It does not buy credits, change plans or payment methods, update auto-reload settings, or pay invoices.

Authentication

All requests require a workspace API key:
The examples use $API_KEY for your API key. The key determines the workspace; you do not supply a workspace ID. See Authentication.

Request

No query parameters, sorting, or pagination are supported.

Response

200 OK — returns one Billing object directly. All workspaces use the same top-level structure. plan and payment_collection identify the billing arrangement: Exactly one accounting object is populated: prepaid workspaces have prepaid and postpaid: null; postpaid workspaces have prepaid: null and postpaid.

Example: standard prepaid

All names, domains, identifiers, amounts, URLs, and timestamps in these examples are illustrative.

Billing fields

Money values are decimal strings such as "20.00"; credit quantities and activity costs are integers. Example prices are illustrative, not universal rates. credit_costs matches Usage.

Prepaid accounting

spent_this_month measures payments, rather than credits consumed multiplied by current pricing. Lifetime credits added can include free grants. auto_reload contains enabled, the credit-balance threshold, the purchase amount, and the purchased credits. monthly_limit contains enabled and its money amount. A disabled configuration may retain its saved values; null means the feature is not applicable or has no configuration.

Example: contract prepaid

This is an alternative fictional account arrangement. Invoice collection can use a card or bank transfer; it does not require bank transfer in every case. Contract prepaid does not use auto reload or its monthly limit.

Postpaid accounting

Postpaid usage resets with the authoritative billing calendar month. Historical invoices remain in billing_history. Usage and Billing follow the same accounting boundaries.

Example: card postpaid

Payment is due immediately and collected using the configured card; payment_terms_days is 0.

Example: invoice postpaid

The customer pays issued invoices under the configured terms. This example uses Net 30; the actual value follows the billing agreement and is not a fixed enum. Invoice collection may use a card or bank transfer.

Payment method

Card display metadata uses type, network, and last4. A bank-transfer method uses {"type": "bank_transfer"}. payment_method: null means no method is configured. payment_collection describes the collection arrangement; payment_method describes the preferred or configured method. They should not be inferred from one another. Full card or bank account information and processor credentials are never returned.

Billing history

History is ordered newest first by created_at and includes the workspace’s customer-facing history across prior billing arrangements. The same transaction structure is used for all models.

Types and statuses

  • grant: free credits; amount is "0.00", status is paid, and an invoice link may be absent.
  • reload: self-service prepaid credit purchase.
  • prepaid: funded contract prepaid purchase.
  • postpaid: monthly usage invoice.
paid means fully settled or a free grant. unpaid includes an issued invoice awaiting payment, including a partially paid invoice or one with a failed payment attempt. voided means canceled and no longer payable. These are financial statuses; the API does not expose every internal payment-attempt state. An unavailable invoice document uses invoice_url: null. History is returned in the Billing response rather than through a paginated subresource. Use Usage for daily and monthly activity reporting and Workspace Info for the billing contact. Financial configuration changes follow the existing 1eye billing workflows.

Errors

Errors use the standard error envelope. Use request_id when contacting support.