Skip to main content

Overview

TextQL exposes usage data through several channels. Each answers a different question — pick the right one before building.

Data Sources Reference

Usage API — GET /v1/billing/usage

ACU consumption aggregated by user × time bucket. Use for billing dashboards and spend tracking across teams. Contains: organization, email, category (llm_tokens, compute_hours, cell_executions), acu, start_datetime, end_datetime Does not contain: per-conversation breakdown, raw token counts, cost in dollars

Chat List API — POST /v1/chat/list

Returns all conversations in the org across every source. Requires an admin API key — a member-scoped key silently returns only that member’s chats.
Contains: chat_id, title, source (Slack, UI, playbook), creator (email), created_at, updated_at Does not contain: token counts, cost, message content Key parameters:

GetLlmUsage — per-conversation tokens and cost

Returns token breakdown and estimated cost for a specific chat. Requires an admin API key for include_costs.
Contains: one record per LLM call within the chat — input_tokens, output_tokens, cache_creation_input_tokens, cache_read_input_tokens, model_name, timestamp, and estimated_cost (admin only). Sum across the array for conversation totals. Does not contain: ACU values, message content Typical pattern: call POST /v1/chat/list to get all chat_ids, then call GetLlmUsage for each.

Chat API — GET /v2/chats/{id}

Returns the full content of a single conversation including messages.
Contains: message content, source, participants, timestamps Does not contain: token counts, cost
The TextQL Usage connector (visible inside Ana) contains the same thread-level fields as the Chat List API but is designed for interactive querying inside Ana — not for backend polling or external integrations. It does not contain ACU values or dollar cost.
TextQL Usage connector in chat
Base URL: https://app.textql.com/v1/billing

Authentication

All requests require a Bearer token. Your token is a Base64-encoded string in the format {member_id}:{api_token}, created in Settings → Developers → API Keys. Pass it in one of two ways:

Your First Request

Fetch the last 90 days of usage for your organization with a single call:
Response:
Each record represents one user’s usage within one time bucket, for one category.

Parameters

All parameters are optional query parameters on GET /usage. Unrecognized query parameters are rejected with 400 invalid_parameter — in particular, the response fields start_datetime / end_datetime are not valid request filters; use start_date / end_date.

Date Range

Timezones are expressed through the RFC 3339 UTC offset (e.g. 2026-07-04T20:00:00-04:00). The offset of start_date (or of end_date when start_date is omitted) also controls:
  • Alignment of day and month buckets (days start at local midnight for that offset)
  • The offset used to render start_datetime / end_datetime in the response
Remember to URL-encode + in positive offsets as %2B (e.g. 2026-07-01T00:00:00%2B05:30).

Granularity

Controls the size of each time bucket. Defaults to day.

Filtering

By organization — useful for tenants with multiple orgs:
By user email — case-insensitive:
By usage category:
Filters can be combined freely:

Sorting

Use the sort parameter to control result order. Prefix with - for descending.

Pagination

Use pagination.total_count in the response to calculate how many pages exist.

Code Examples

Python — fetch all records across pages:
JavaScript:

Response Fields

Error Reference

Troubleshooting & Support

If you’re still running into issues, contact support at support@textql.com and include the full request URL and response body.