Billing API

The VARICON Billing API provides a programmable interface for usage tracking and anomaly-based pricing.

It allows systems to:

record anomaly usage events
retrieve billing summaries
understand how anomaly intelligence translates into cost

Core concept

Billing is based on a single unit:

1 enriched anomaly = 1 billable unit

Only anomalies that enter the intelligence layer are billable.

API structure

Resource	Description
`/v1/usage/events`	Record anomaly usage events
`/v1/usage/summary`	Retrieve aggregated billing data

Record usage events


POST /v1/usage/events

Records anomaly events that may become billable.

Request


{
  "events": [
    {
      "fingerprint": "fp_hidden_error",
      "timestamp": 1710000000,
      "count": 1,
      "type": "enriched_anomaly"
    }
  ]
}

Fields

Field	Type	Description
fingerprint	string	Deterministic anomaly identifier
timestamp	number	Event timestamp (unix)
count	number	Number of occurrences
type	string	Event type (`enriched_anomaly`)

Response


{
  "status": "accepted",
  "processed_events": 1,
  "billable_events": 1
}

Retrieve usage summary


GET /v1/usage/summary?month=2026-03

Response


{
  "month": "2026-03",
  "total_anomalies": 82000,
  "enriched_anomalies": 72000,
  "billable_anomalies": 62000,
  "free_allowance": 10000,
  "cost_usd": 62.0
}

Idempotency

Usage events must be idempotent.

Deduplication is based on:

fingerprint
timestamp

Repeated submissions of the same event do not increase billable usage.

Fail-open behavior

The billing system follows the VARICON fail-open model.

If the Billing API is unavailable:

pipeline execution continues
anomaly extraction is unaffected
usage is cached locally
retries are performed asynchronously

Billing only occurs when events are successfully processed.

Metering boundary

Billing occurs only after enrichment.

detection → not billed
extraction → not billed
fingerprinting → not billed
enrichment → billed

This ensures pricing is aligned with delivered intelligence, not raw activity.

Event lifecycle

An anomaly moves through the following billing states:

detected (free)
fingerprinted (free)
enriched (billable)
recorded (usage event)

Only step 3 creates billable units.

Future extensions

The Billing API may evolve to support:

batch-level pricing controls
usage attribution per service
organization-level aggregation
cross-run anomaly correlation

Design principles

The Billing API is designed to be:

deterministic (fingerprints ensure stable billing)
fail-open (never blocks CI pipelines)
usage-based (aligned with anomaly intelligence)
transparent (predictable and observable in CI)

Summary

The VARICON Billing API exposes pricing as a first-class system interface.

It enables:

precise usage tracking
predictable cost modeling
alignment between system behavior and billing

Billing is not based on traffic. It is based on understanding anomalies.