Billing

Billing

api/views/billing_views.py owns the billing settings surface. Every endpoint is tenant scoped and requires both authentication and membership to the current tenant.

Endpoint family

• GET /api/v1/billing/plan/ — current subscription plan and next billing date
• GET /api/v1/billing/usage/ — current-month usage metrics
• GET /api/v1/billing/invoices/ — invoice list
• GET /api/v1/billing/invoices/<invoice_id>/pdf/ — invoice PDF
• GET|POST /api/v1/billing/payment-method/ — payment-method management

Authorization and tenant rules

Billing requires:

• an authenticated user
• the current tenant resolved by middleware or header
• membership in that tenant

The helper _require_tenant() rejects requests that do not supply a tenant or where the user is not a member.

Data sources

Billing is not computed from a single table:

• plan information comes from api.models.billing.get_plan_info
• usage aggregates come from AIStudioProcessing
• member counts come from TenantMembership
• invoice data comes from Invoice
• payment method data comes from PaymentMethod

That means billing reads from both tenant data and processing telemetry.

Usage semantics

BillingUsageView reports four buckets:

• documents processed
• API calls
• token consumption
• team members

The first three are derived from AIStudioProcessing rows for the current month; the team-member count comes from the tenant membership table. If aggregation fails, the endpoint falls back to zeroes rather than breaking the settings page.

Validation focus

• tests/unit billing coverage for tenant membership and usage aggregation
• tests/integration billing settings-page requests

Scope boundary

Billing is a settings-page concern. It should not be confused with document-processing telemetry, although both may read from AIStudioProcessing or tenant membership data.