Latest API and SDK updates. Subscribe via RSS · Discord
Summary
You can now track cumulative usage over time. The new usage endpoint returns running totals of storage, messages, threads, inboxes, domains, and pods — for your whole organization, a single pod, or a single inbox. Event counts also move to a dedicated /metrics/events path, so the metrics API now cleanly separates “what happened” (events) from “what you have” (usage).
What’s new?
New endpoints:
GET /v0/metrics/usage- Cumulative usage series for the organization.GET /v0/pods/:pod_id/metrics/usage- Cumulative usage series for a pod.GET /v0/inboxes/:inbox_id/metrics/usage- Cumulative usage series for an inbox.GET /v0/metrics/events(and pod/inbox variants) - The canonical path for event counts, replacing bareGET /v0/metrics.
New features:
- Usage series: Each point is the running total of a usage type at that timestamp, not the change within the bucket. An idle scope renders a flat line at its current level, so charts stay meaningful even with no activity in the window.
- Usage types:
storage_bytes,message_count,thread_count,inbox_count,domain_count, andpod_count. Filter with theusage_typesquery parameter, or omit it to get every type the scope carries. Inboxes carry the first three; pods addinbox_countanddomain_count; organizations addpod_count. - Bucketing:
periodsets the bucket size in seconds. The range divided byperiodmust not exceed 1000 buckets — narrow the range or coarsen the period for fine-grained series.
Changes:
GET /v0/metrics(and its pod/inbox variants) is replaced by/metrics/events. The old path still responds, so existing clients keep working, but it’s removed from the docs and SDKs — useclient.metrics.queryEvents()in place ofclient.metrics.query().- Metric queries now clamp a future
endto the current time instead of returning phantom future points, andperiod/limitmust be whole numbers. - The documented metric event types now match what the API accepts: added
message.received.spam,message.received.blocked,message.received.unauthenticated, anddomain.verified; removedmessage.delayed, which the API never accepted.
Use cases
Build agents that:
- Chart storage growth over time and archive old threads before hitting quota
- Monitor message and thread volume per inbox to spot runaway automations
- Verify cleanup actually happened by watching usage drop after bulk deletes
- Compare pods by inbox and domain footprint to balance workloads
Check out the Metrics API reference for full parameter details.
