Usage Ingestion
Monitor the metering pipeline in real time — pulse KPIs, source health, data quality, and performance — check per-meter health, inspect recent usage events, and bulk-upload event files.
Usage Ingestion
Usage Ingestion (Intelligence → Usage Ingestion) is the operational view of your metering pipeline: what's flowing in, how healthy it is, and the ability to inspect or bulk-load events.
Renamed from "Ingestion & Billable Units" on 2026-06-16. The old label collided with the Billable Units item under Catalog, where you define meters. This page is where you watch the usage that hits them — the name now reflects that.
Tabs
Overview (monitoring)
A pulse KPI strip — Events/min · Success Rate · Active Sources · Avg Latency — plus per-source metrics grouped by source type:
Each source shows event count, success rate, last-event time, and status (HEALTHY, DEGRADED, DOWN, THROTTLED). The Overview also reports data quality (validation pass rate, schema violations, dead letters, top errors) and performance (P99/P95/avg latency, throughput, backlog depth, throttling alerts).
Billable Units (metering health)
Per-meter health for every billable unit — event volume, error rate, latency, and Z-score anomaly detection — so a meter that suddenly stops, spikes, or starts erroring gets caught before it corrupts billing. This is the former standalone "Metering Health" page, folded in here on 2026-06-14; see Metering Health for the full breakdown.
Recent Events
A paginated table of raw usage_events, filterable by customer, metric name, product type (API, AGENTIC_API, AI_AGENT, MCP_SERVER), and time range. Each event shows its status:
Click a row to open the full JSON payload in a detail drawer, or Export events to S3 or email.
File Upload
Drag-drop a CSV, JSON, NDJSON, or XML file (up to 50 MB). The wizard previews the file, maps columns to customerId, metricName, quantity, occurredAt, and idempotencyKey (with default metric/customer overrides), then ingests. Upload jobs track QUEUED → PROCESSING → COMPLETED (or PARTIAL / FAILED) with accepted/failed row counts.
Execution status on events
If a rate plan prices a billable unit as Outcome-Based, each event's executionStatus decides what it bills at. The field is optional on every product type.
curl -X POST https://api.aforo.ai/v1/ingest \
-H "X-API-Key: $AFORO_API_KEY" \
-H "Content-Type: application/json" \
-d '{"customerId":"cus_123","metricName":"agent_calls","quantity":1,
"occurredAt":"2026-07-01T10:00:00Z","idempotencyKey":"run_7f3a",
"executionStatus":"PARTIAL"}'
import os, requests
requests.post("https://api.aforo.ai/v1/ingest",
headers={"X-API-Key": os.environ["AFORO_API_KEY"]},
json={"customerId": "cus_123", "metricName": "agent_calls", "quantity": 1,
"occurredAt": "2026-07-01T10:00:00Z", "idempotencyKey": "run_7f3a",
"executionStatus": "PARTIAL"}).raise_for_status()
Gateway plugins and the MCP, gRPC and GraphQL SDKs set the field for you — see Sending outcomes for who sets what. File Upload has no status column: uploaded events arrive without a status and bill at full weight on Outcome-Based plans, so send outcome-weighted usage through the API instead.
The Execution Status filter on API, agentic API, AI agent and MCP billable units matches this same field, so a billable unit can count only, say, successful calls.