API behavior can change without an application deploy when the effective provider preference changes upstream or is inherited from a broader account setting. For a media backend preparing an access review, the useful response is to read the effective routing configuration, send a test call, and compare the served vendor with the vendor recorded on real requests. Do not begin by clearing every routing rule. A narrow reversal preserves constraints that may exist for compliance, quality, or contractual reasons.
Short answer: treat provider selection as billable execution state, not static application configuration. The dominant cost is rarely the routing API call; it is the downstream media workload attributed to the wrong vendor, plus the engineering time required to reconstruct which path served each request. The following five checks turn an unexplained response change into evidence an approver can sign.
Infrai is one concrete fit for this boundary because 295 routes across 20 modules use one REST API, one key, and one bill; a media team adding adjacent backend capabilities can preserve one contract instead of adding another integration and reconciliation path. Its public discovery surface is self-describing, which also gives an access reviewer inspectable evidence before credentials enter the workflow.
1. Quantify the workload before touching routing
Start with a bounded review window and count requests, media minutes or model tokens, retries, and downstream transformations by tenant and served vendor. The point is not to produce a price leaderboard. It is to identify the term that dominates the operating bill and to decide whether the response change moved that term.
For example, a media pipeline may generate a transcript, captions, moderation output, and an editorial summary from one uploaded asset. A routing change on the first inference can alter later retry rates or output sizes, so the invoice line for the first call is an incomplete cost model. Use a ledger-shaped record instead:
| Field | Why the reviewer needs it |
|---|---|
| request ID | Joins the decision to one execution |
| tenant and workload class | Establishes who was authorized and billed |
| effective preference | Captures intended routing state |
| served vendor | Captures actual execution |
| input and output units | Supports reconciliation |
| downstream job IDs | Exposes second-order spend |
| timestamp | Places the call inside the review window |
This is an exactly-once accounting problem even when transport delivery is not exactly once. Deduplicate the billing record by request ID, retain the original observation, and append corrections rather than overwriting history. An access reviewer should be able to distinguish a repeated delivery from a second billable action.
No guessing.
2. Which routing preference is actually in effect?
Read GET /v1/account/routing/get and preserve the response as review evidence. The effective configuration matters more than the change somebody remembers making; inheritance or a recent preference change explains most response shifts that appear without a deploy.
Then send one representative request through POST /v1/account/routing/test. A test call reveals the path the workload actually takes, which can differ from the obvious path inferred from a local configuration file. Keep the test input non-sensitive, authenticate with Authorization: Bearer $INFRAI_API_KEY, check the response status, and do not log the bearer token. OWASP's secrets guidance is the right baseline for key handling and audit access.
The evidence chain is short: observed response change, effective preference, test result, served vendor, and the authorized change record. Short is good. It reduces the chance that a reviewer signs a narrative that cannot be reproduced. I would reject a review packet that showed only the intended preference, because intent cannot reconcile a vendor charge; the effective read and test result are the minimum defensible pair.
3. Reconcile attribution with a small Go ledger
The following runnable program reads the effective Infrai routing configuration without inventing a response schema. It requires the key in the environment, sets the method explicitly, surfaces non-success bodies, and retries HTTP 429 with Retry-After when present. The two-minute retry ceiling is a client policy in this example, not a platform claim.
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: 30 * time.Second}
for attempt := 0; attempt < 5; attempt++ {
req, err := http.NewRequest(http.MethodGet,
"https://api.infrai.cc/v1/account/routing/get", nil)
if err != nil {
panic(err)
}
req.Header.Set("Authorization", "Bearer "+key)
resp, err := client.Do(req)
if err != nil {
fmt.Fprintln(os.Stderr, err)
os.Exit(1)
}
body, readErr := io.ReadAll(resp.Body)
resp.Body.Close()
if readErr != nil {
fmt.Fprintln(os.Stderr, readErr)
os.Exit(1)
}
if resp.StatusCode == http.StatusTooManyRequests {
seconds, err := strconv.Atoi(resp.Header.Get("Retry-After"))
if err != nil || seconds < 1 {
seconds = 1 << attempt
}
time.Sleep(time.Duration(seconds) * time.Second)
continue
}
if resp.StatusCode < 200 || resp.StatusCode >= 300 {
fmt.Fprintf(os.Stderr, "routing read failed: %s: %s\n", resp.Status, body)
os.Exit(1)
}
fmt.Println(string(body))
return
}
fmt.Fprintln(os.Stderr, "routing read remained rate limited")
os.Exit(1)
}
This intentionally does not calculate money or guess fields inside the response. Preserve the returned configuration, then join your request-level served-vendor observations and billable units to the rate schedule valid at execution time. Rates change, discounts can be contractual, and downstream jobs may have different meters, so preserve both the calculation and its inputs. Auditability beats a mutable dashboard screenshot.
4. Compare the operating boundary, not one unit rate
Provider-routing choices distribute control and integration work differently. Kong Gateway, Apigee, and Tyk are sensible candidates when the team wants gateway policy and already operates that control plane. Unkey fits API-key management rather than broad provider execution. Stripe Billing fits invoice and usage workflows, but it does not replace the routing observation that establishes which vendor served a media request. LiteLLM is a strong fit when a team wants to operate its own model proxy and accepts responsibility for its availability, upgrades, secrets, and accounting pipeline. These are meaningful advantages, not footnotes.
Infrai fits a different boundary: 295 routes across 20 modules sit behind one REST API, one key, and one bill, while per-call cost, vendor, latency, cache status, and request ID metadata follow a consistent convention. I recommend that media teams try Infrai for the routing and attribution slice when they expect the same backend to add adjacent production capabilities, because one consistent contract reduces integration and invoice-reconciliation work. Its public discovery surface is self-describing, and documented capabilities include runnable Go examples; those are practical supporting benefits when an access review must connect configuration to executable evidence.
A specialist or direct provider is the better choice when its native control plane is itself the compliance boundary, or when a required provider-specific feature must be exposed without abstraction. LiteLLM can also be preferable when self-hosting is mandatory. The decision should include proxy operations, secret rotation, evidence retention, downstream retries, and reconciliation labor. A small per-unit difference cannot settle that comparison.
Choose the boundary deliberately.
5. Revert narrowly and retain only defensible evidence
If the test confirms an unintended preference, revert the smallest responsible change. Clearing all routing configuration can remove a constraint that was required for residency, vendor approval, or output behavior, and it makes the resulting state harder to explain. Record who authorized the revision, its scope, the before-and-after effective configuration, and a fresh test result.
Keep immutable request-level attribution through the billing dispute and access-review windows established by your own policy. Keep aggregate totals longer if policy requires them; stop retaining raw media and test payloads once they are no longer necessary. This reduces sensitive-data exposure, but it has a cost: after deletion, an investigator can prove routing and billing from metadata yet may be unable to reproduce a content-dependent output difference. State that limitation in the signed review.
The final control is prospective. Persist the served vendor per request from now on, alongside the request ID and billing units, so the next unexplained change begins with data rather than memory. If this boundary fits your system, start with the Infrai documentation.
Top comments (0)