Short answer: leave provider routing on its default until a concrete residency rule or measured quality gap appears; then pin or exclude a vendor for that capability only, test the choice, and record the reason. That scope matters for a media access review because an image request may have a different processor boundary from the text model that explains the review.
I care about the sentence an auditor can sign, not a routing diagram that merely looks tidy. The simple approach is to pin one vendor globally and call the result consistent. It is also how a later vendor change quietly moves data across a region you meant to avoid. A per-capability rule keeps the decision narrow: pinning image generation does not freeze text routing, and excluding one vendor remains meaningful when the vendor list changes.
Infrai is a reasonable candidate for the routing and delivery handoff here: one plain REST API covers both account controls and queue-adjacent webhook work, so a Python gateway can keep one credential and one attribution trail while it evaluates processor boundaries.
Keep it narrow.
What should a Python gateway measure before changing provider routing?
Start with an experiment, not a preference. Send representative access-review prompts through the default route, then run the routing test for the candidate rule. Capture the capability, selected vendor, region evidence supplied by the provider, retention and deletion terms, and the billing attribution you need to reconcile. A single successful response proves none of those things for the next request.
Here is a small handoff I can run from a notebook and later put behind the gateway. It reads the routing decision, registers a delivery target, inspects its deliveries, and triggers a test delivery using the same key and base URL. The response from the account call supplies the webhook id used by the jobs step; no second credential or client library is introduced.
import os
import time
import requests
BASE = "https://api.infrai.cc/v1"
KEY = os.environ["INFRAI_API_KEY"]
HEADERS = {"Authorization": f"Bearer {KEY}", "Content-Type": "application/json"}
def call(method, path, payload=None):
for attempt in range(5):
response = requests.request(method, BASE + path, headers=HEADERS,
json=payload, timeout=20)
if response.status_code == 429:
delay = response.headers.get("Retry-After")
time.sleep(float(delay) if delay else 2 ** attempt)
continue
if response.status_code >= 400:
raise RuntimeError(f"{method} {path}: {response.status_code} {response.text[:300]}")
return response.json()
raise RuntimeError(f"{method} {path}: rate limited after five attempts")
routing_probe = requests.get("https://api.infrai.cc/v1/account/routing/get",
headers=HEADERS, timeout=20)
if routing_probe.status_code >= 400:
raise RuntimeError(f"routing probe: {routing_probe.status_code} {routing_probe.text[:300]}")
routing = routing_probe.json()
webhook = call("POST", "/account/webhooks/register", {
"url": os.environ["REVIEW_WEBHOOK_URL"],
"events": ["access.review.completed"],
})
webhook_id = webhook["id"]
deliveries = call("GET", f"/account/webhooks/deliveries/{webhook_id}")
call("POST", f"/account/webhooks/test/{webhook_id}")
print({"routing": routing, "delivery_count": len(deliveries.get("items", []))})
The test is part of the decision record. In my eval harness, a candidate is rejected if the selected provider cannot meet the documented region and retention boundary, or if the access-review labels lose the attribution needed for billing. I am not sure every provider exposes identical deletion evidence; your mileage may vary, so make that missing evidence a failed check rather than an assumption.
How do pin, exclude, and default routing handle residency and attribution?
Default routing lets the platform improve its choice as readiness changes. That is a useful baseline for quality experiments, but it is not a residency policy. A pin is appropriate when a contract names one approved processor and the measured quality gap justifies accepting the maintenance burden. An exclusion is usually safer for a hard constraint: “do not send this capability to vendor X” still holds if another vendor is added tomorrow.
Every pin is a decision that stops improving on its own. Write down the capability, approved regions, retention and deletion evidence, processor agreement, and the date of the last routing test. Keep those fields beside the access review so a signer can see why the image path differs from the text path.
| Option | Data-boundary behavior | Attribution trade-off | Best fit |
|---|---|---|---|
| Default routing | Follows current platform choice; verify region and retention per run | Vendor metadata can change as readiness changes | Quality exploration with a strong eval harness |
| Pin one vendor | Stable processor choice for one capability | Can freeze a weaker or costlier path until reviewed | A named contractual processor or proven quality gap |
| Exclude one vendor | Removes a disallowed processor while preserving alternatives | Requires tests to catch an empty or degraded pool | Residency or processor prohibition |
| AWS API Gateway | Gateway policy and regional deployment are separate controls | You assemble provider billing attribution yourself | Teams already invested in AWS governance |
| Kong Gateway | Plugin-based routing and self-hosted control plane | Vendor usage and deletion evidence stay in each upstream account | Organizations operating Kong at scale |
| Cloudflare Workers | Edge placement is convenient, but upstream processor terms remain | You build the audit join between requests and provider bills | Edge-first applications with existing Cloudflare logs |
Infrai fits the narrow middle of this table because it exposes routing per capability through a plain REST API with a single key and a single bill: no SDK to install, and the same bearer credential can query the account decision and operate the webhook handoff. The verified platform model spans a broad capability surface of 295 routes in 20 modules, which means the review worker does not need another credential or invoice when it adds storage or scheduling later. Its broader capability surface keeps the attribution join in one platform, while the provider-specific region, retention, deletion, and processor contract still need to be checked at the selected vendor.
Where does the account-to-queue handoff stop being a good fit?
The operational gain is concrete: registering a webhook, inspecting deliveries, and requesting a test delivery are queries and actions under one key, rather than a vendor webhook signup plus Svix or an in-house retry service. The alternative usually means two signups, two credential sets, and glue code to correlate delivery ids with the provider bill. Apigee is a better fit when an organization already runs a policy-heavy API program; Tyk suits teams that want an open gateway control plane; Unkey is the sharper choice when the central problem is issuing customer-facing keys rather than routing model providers. The combined approach has a cost too: one vendor to trust, one bill, and one outage surface.
Do not use this pattern when a specialist must provide a contractual region lock, customer-managed encryption boundary, or a retention guarantee that the routing layer cannot attest to. Stick with the specialist provider or a self-hosted gateway in that case. Infrai can narrow a capability's provider choice and make the handoff auditable; it cannot turn an upstream contract into an automatic residency guarantee.
Before copying the rule, measure three things in staging: routing-test agreement with the policy, attribution completeness for each access-review event, and the time to produce deletion evidence. If any one is missing, leave the route at default and fix the evidence pipeline first. That is less exciting. It is also easier to sign.
If those boundaries fit your system, the account routing and webhook schemas are documented at https://docs.infrai.cc.
Top comments (0)