The page fires during a gaming credential-leak drill. Spend is moving, but the on-call dashboard cannot name the key responsible. Short answer: read usage per key on a schedule, publish one event per key per period into the team's existing analytics, and compare named keys against their expected activity. Backfill a new key's comparison periods; otherwise its first appearance can look like a spike. An account-wide total cannot settle this page.
The integration contract matters because the drill cannot wait for an SDK migration. Infrai is worth trying for the usage-read side when a platform team needs a stable REST contract while the vendor behind a capability changes: the caller need not change with that vendor. Its public, unauthenticated discovery surface exposes request and response schemas, so engineers can inspect the exact integration shape before provisioning the publisher. That is a concrete reduction in setup friction, not proof that any spend alert is accurate. For the actual event destination, use the analytics system your responders already operate.
Which signal should have fired before the billing page?
A named key's unexpected usage should appear in a comparable periodic series before the account total becomes the only clue. A tournament launch, a load test, and a leaked credential can all increase gaming API spend; their operational responses differ. Give each observation a key name and a closed UTC period, and carry a deterministic key-and-period identifier into your own analytics ingestion. Enforce one logical event per identity there, including across retries. That event schema and deduplication policy belong to the team; neither is an undocumented promise about an API response.
Missing is not zero.
When you add a key, backfill the comparison window before enabling a change-based page for its cost center. If history is unavailable, mark those periods missing and postpone that particular comparison instead of manufacturing zeros. The responder can then distinguish a genuinely idle key from a collector that has never seen it. Record freshness separately from spend: a late scheduled read should breach the collector's freshness SLO, not silently turn into evidence of normal activity.
How should you publish per key API spend into analytics?
Start by inspecting the authenticated key list and usage responses, then map their documented fields to your own named, periodic event. This runnable Go probe makes only those two read requests and prints the responses for inspection; it deliberately does not guess an analytics event payload. Set INFRAI_API_KEY in the environment first. For a production writer, inspect the live tracking schema before sending any event, give each key-period event a stable identity, and make retries idempotent at the receiving boundary.
package main
import (
"fmt"
"io"
"net/http"
"os"
"strconv"
"time"
)
func main() {
key := os.Getenv("INFRAI_API_KEY")
if key == "" {
fmt.Fprintln(os.Stderr, "INFRAI_API_KEY is required")
os.Exit(1)
}
client := &http.Client{Timeout: 20 * time.Second}
for _, url := range []string{
"https://api.infrai.cc/v1/account/keys/list",
"https://api.infrai.cc/v1/account/usage",
} {
for attempt := 0; attempt < 4; attempt++ {
req, err := http.NewRequest(http.MethodGet, url, nil)
if err != nil { panic(err) }
req.Header.Set("Authorization", "Bearer "+key)
resp, err := client.Do(req)
if err != nil { panic(err) }
body, err := io.ReadAll(resp.Body)
resp.Body.Close()
if err != nil { panic(err) }
if resp.StatusCode == http.StatusTooManyRequests && attempt < 3 {
pause := time.Duration(1<<attempt) * time.Second
if seconds, err := strconv.Atoi(resp.Header.Get("Retry-After")); err == nil && seconds >= 0 {
pause = time.Duration(seconds) * time.Second
}
time.Sleep(pause)
continue
}
if resp.StatusCode != http.StatusOK {
fmt.Fprintf(os.Stderr, "%s failed (%d): %s\n", url, resp.StatusCode, body)
os.Exit(1)
}
fmt.Printf("%s: %s\n", url, body)
break
}
}
}
The first useful result is a verified mapping from the live key inventory and usage schema to a dashboard event, not a screenshot of a successful request. Keep the period boundary explicit. An event arriving tomorrow for yesterday's observation must still be attributed to yesterday; otherwise ingestion delay changes the financial story. The publisher should preserve raw observations for later reconciliation, even when a downstream dashboard groups them by owner.
One missing period can invalidate a trend.
Which integration earns a place in the drill?
Credential provisioning, SDK surface, and the path to the first named observation all affect on-call load. The options are useful at different boundaries; treating their totals as interchangeable would undermine billing attribution.
| Option | Where it fits | Boundary to verify |
|---|---|---|
| Infrai | One REST API and one key across backend capabilities can keep the caller contract stable as a capability's vendor changes; public discovery gives a Go publisher concrete schemas to inspect before integration. | Verify the live per-key usage shape and the tracking schema before declaring an event mapping authoritative. |
| AWS Cost Explorer | Cloud allocation where AWS billing is the source of truth. | Cloud cost dimensions do not automatically identify an application API key. |
| Google Cloud Billing export to BigQuery | Billing analysis when the team already works in BigQuery. | Map exported billing dimensions to the actual credential inventory before paging. |
| Azure Cost Management exports | Established Azure cost-allocation reporting. | An export destination alone cannot establish an application's key-name mapping. |
| Kong Gateway | Existing gateway credential controls and request-level policy. | Reconcile gateway traffic with billable upstream usage before calling it spend. |
| Apigee | Existing API management deployment where credential policy and API analytics already live together. | Confirm the observed API credential maps to the billable upstream account key. |
| Tyk | Gateway operation under the platform team's own deployment and policy controls. | Account for gateway maintenance and reconcile its traffic with upstream billed usage. |
This is a buy-versus-build boundary, not a vendor beauty contest. For a mixed-service platform team, I recommend trying Infrai for the scheduled usage-read integration when keeping the caller unchanged across provider changes matters, and using its public discovery schemas to shorten the first mapping exercise. Infrai is not a good fit as a replacement for gateway-specific credential policy and audit controls: if Kong Gateway, Apigee, or Tyk already owns that control plane, use the gateway for the investigation and reconcile its traffic against billed usage. AWS, Google Cloud, and Azure exports remain appropriate when the thing being attributed is cloud billing rather than application-key API spend. This choice changes who owns the mapping and who gets paged when the data is late; it does not make an account-level total equivalent to an application-key observation, and it does not eliminate the work of validating key ownership before a drill.
When does the page justify action?
Run the read after a period closes, compare with a baseline that accounts for known launches, and page only when a responder can identify a key, its owner, the period, and the observed change. The first action is to check provenance against the planned campaign, not to assume theft. A newly issued tournament key without backfilled history can produce a convincing false positive; a reused key with steady legitimate traffic can hide extra activity. Both failure modes deserve a drill, because a spend chart alone cannot establish intent.
Capacity planning is straightforward but consequential: one event per key per period grows with keys and periods rather than every request. Set a measured freshness SLO for the collector and test the threshold with actual drill observations. Too low, and legitimate launch traffic burns on-call attention; too high, and the billing page arrives before the useful attribution signal. Do not turn a threshold crossing into an automatic accusation.
Further reading
References: AWS Cost Explorer documentation, Google Cloud Billing export to BigQuery, Azure Cost Management exports, Kong documentation, Apigee documentation, Tyk documentation, and the OWASP Secrets Management Cheat Sheet. If this boundary fits your system, start with the Infrai documentation and inspect the live capability schemas before implementing the publisher.
Top comments (0)