Defining Metrics

Create metrics that capture the usage signals your pricing model is built on.

What Is a Metric?

A metric is the definition of a billable signal. It tells ABAXUS what to measure and how to collapse raw events into a single usage total for a billing period. A metric does not determine price — that’s the price plan’s job. A metric only answers: “Given all events for this customer in this period, what is the usage number?”

Metrics are defined once and referenced by their key everywhere else in the system — in price plans, events, usage queries, and entitlements. The key is the stable identifier; the name is the human-readable label. Never change a metric’s key once it’s in use, as doing so would break the association between historical events and any plans referencing it.

The 7 Aggregation Types

sum

Adds all event values together. Use this for any usage that accumulates — API calls, database writes, tokens processed, emails sent, data transferred.

1

{ "key": "api_calls", "aggregation": "sum" }

An event with value: 1 and another with value: 5 in the same period produces a total of 6.

count

Counts the number of events submitted, ignoring the value field. Use this when the event itself represents the unit — number of deployments, number of webhook deliveries, number of model inference requests.

1

{ "key": "deployments", "aggregation": "count" }

Three events submitted in the period = usage total of 3, regardless of their values.

max

Takes the highest event value seen in the period. Use this for peak measurements — peak concurrent connections, peak memory allocation, peak active users at a given instant. Useful when you want to bill for capacity rather than consumption.

1

{ "key": "peak_concurrent_users", "aggregation": "max" }

min

Takes the lowest event value in the period. Rarely used for billing directly, but useful for metrics like minimum committed throughput or calculating headroom.

1

{ "key": "min_guaranteed_throughput", "aggregation": "min" }

last

Takes the most recent event value by timestamp. Use this for snapshots that represent a current state rather than accumulated activity — seat count, current storage allocation, active licenses. Send an event whenever the value changes; ABAXUS uses the last one in the period.

1

{ "key": "active_seats", "aggregation": "last" }

unique_count

Counts distinct values of a specified property across all events. Use this for counting unique entities — unique users who made API calls, unique IP addresses, unique feature invocations. You specify which event property to count distinct values of using the unique_on field.

1

{ "key": "monthly_active_users", "aggregation": "unique_count", "unique_on": "user_id" }

When sending events for this metric, include properties.user_id in each event payload.

percentile

Computes a specified percentile of all event values in the period. Use this for latency-based billing, p95 throughput commitments, or any SLA-linked pricing. Specify the target percentile as percentile_value (e.g., 95 for p95).

1

{ "key": "p95_latency_ms", "aggregation": "percentile", "percentile_value": 95 }

The key Field

The key is the system-wide identifier for a metric. Rules:

  • Lowercase letters, numbers, and underscores only
  • Must be globally unique within your ABAXUS instance
  • Cannot be changed after events have been recorded against it
  • Referenced in price plan charges, event payloads, and usage queries

Good keys are descriptive and stable: api_calls, data_egress_gb, active_seats, compute_minutes, tokens_processed.

Metric Versioning and Deactivation

Metrics cannot be deleted once events have been recorded against them. Instead, you can deactivate a metric (PATCH /v1/metrics/:key with status: "inactive"). A deactivated metric:

  • Rejects new events (returns 422 with a clear error)
  • Preserves all historical events and aggregates
  • Continues to appear on historical invoices that reference it
  • Can be reactivated if needed

This soft-deactivation model ensures your historical billing data is never corrupted by metric lifecycle changes.

Full curl Example

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

curl -X POST "$ABAXUS_URL/v1/metrics" \
  -H "Authorization: Bearer $ABAXUS_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "key": "api_calls",
    "name": "API Calls",
    "aggregation": "sum",
    "description": "Total number of API calls made by the customer during the billing period",
    "unit_label": "calls"
  }'

For a unique_count metric tracking monthly active users:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

curl -X POST "$ABAXUS_URL/v1/metrics" \
  -H "Authorization: Bearer $ABAXUS_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "key": "monthly_active_users",
    "name": "Monthly Active Users",
    "aggregation": "unique_count",
    "unique_on": "user_id",
    "description": "Unique users who made at least one action this billing period",
    "unit_label": "users"
  }'

After creating a metric, verify it with GET /v1/metrics/api_calls. Once events are flowing, check aggregated totals with GET /v1/usage/summary?customer_id=cust_acme&metric_key=api_calls.