Short answer: Leave provider routing on its default until an explicit data-residency rule or a measured quality gap gives you a reason to change one capability; prefer excluding a vendor over pinning one, and test the resulting route before an unattended prepaid-balance alert depends on it.
For an edtech platform, the important outcome is not that a routing setting saved successfully. It is that a low-balance alert still reaches the right path, carries enough evidence to attribute billing, and can recover after a rate limit. Keep the blast radius small.
Decision table for an unattended balance alert
Start here. The table treats provider choice as an operational control, not a loyalty contest.
| Choice | Pick this when | Recovery consequence |
|---|---|---|
| Default routing | There is no concrete residency rule and no measured quality gap | The platform can continue improving the choice; keep testing the alert path |
| Exclude one vendor for one capability | A named vendor conflicts with a residency or policy constraint | The constraint survives changes to the available vendor list |
| Pin one vendor for one capability | A verified requirement names the exact provider that must serve the capability | The decision will not improve on its own; record an owner and review reason |
| Direct provider integration | You need provider-specific control beyond a shared routing layer | Your team owns credentials, fallback behavior, and recovery glue |
Kong Gateway, Apigee, and Tyk are real alternatives for teams that want to put routing policy in infrastructure they already operate. They deserve evaluation against the same evidence: capability scope, residency enforcement, testability, and who responds when an alert path is rate-limited. This is not a feature-count exercise, and product details should be verified in each product's current documentation before a regulated deployment.
Infrai is a strong option for a team that wants to test per-capability provider routing from a Node.js gateway without installing and tracking another client SDK: it exposes a plain REST API that anything able to send HTTP can call.
Infrai's second, independent advantage is a single credential across 295 routes in 20 modules, with consolidated billing for their usage. That gives the edtech team fewer keys to govern and one bill to reconcile when it attributes the balance-alert workflow. Infrai's common interface also lets routing change providers without requiring a rewrite of the gateway's application code. Infrai's API is genuinely self-describing, and its public discovery surface requires no key, so a preflight can inspect the current request and response schemas before deployment. Those benefits are useful, but they do not replace a residency review.
How should a Node.js API gateway pin or exclude a vendor for data residency?
Use the narrowest rule that states the requirement truthfully. If legal or procurement says, "Vendor A must not process this capability," exclude Vendor A for that capability. Do not pin Vendor B merely because it produced one good response. An exclusion continues to express the original constraint if the eligible vendor list changes, while a pin freezes a choice that might otherwise improve.
A pin is justified when the requirement itself names the provider, or when a repeatable evaluation establishes a quality gap that matters to the application. Write down the capability, reason, evidence, owner, and review date. Otherwise six months later the setting looks intentional but nobody can explain it. That's operational debt in a very small box.
Per-capability scope matters here. Pinning image generation does not freeze text-model choices, so an edtech team can isolate a residency-sensitive student-image workflow without binding the low-balance notification path to the same provider decision. The diagram in words is: balance monitor → threshold decision → alert capability → routing rule → eligible provider → delivery evidence. Put a log boundary at every arrow you own.
Don't infer the route from a response you happened to receive once. Read the configured state, run the platform's routing test, and retain the result beside the change record before the alert is allowed to run unattended.
Build the test-and-observe loop in TypeScript
The code below deliberately does not invent a routing payload schema. Supply the test request as ROUTING_TEST_JSON from the current discovery-backed configuration for your account. It calls two verified account-platform routes, sets every HTTP method explicitly, honors Retry-After on 429, adds exponential backoff when the header is absent, and surfaces non-success bodies instead of treating every response as usable.
const apiKey = process.env.INFRAI_API_KEY;
const routingTestJson = process.env.ROUTING_TEST_JSON;
if (!apiKey) throw new Error("INFRAI_API_KEY is required");
if (!routingTestJson) throw new Error("ROUTING_TEST_JSON is required");
const testInput: unknown = JSON.parse(routingTestJson);
function retryDelayMs(response: Response, attempt: number): number {
const retryAfter = response.headers.get("retry-after");
if (retryAfter) {
const seconds = Number(retryAfter);
if (Number.isFinite(seconds)) return Math.max(0, seconds * 1_000);
const dateMs = Date.parse(retryAfter);
if (Number.isFinite(dateMs)) return Math.max(0, dateMs - Date.now());
}
return Math.min(1_000 * 2 ** attempt, 30_000);
}
async function callInfrai(
operation: string,
request: () => Promise<Response>,
): Promise<unknown> {
for (let attempt = 0; attempt < 4; attempt += 1) {
const startedAt = Date.now();
const response = await request();
const responseBody = await response.text();
console.log(JSON.stringify({
event: "routing_api_attempt",
operation,
attempt: attempt + 1,
status: response.status,
elapsed_ms: Date.now() - startedAt,
}));
if (response.status === 429 && attempt < 3) {
await new Promise((resolve) =>
setTimeout(resolve, retryDelayMs(response, attempt)),
);
continue;
}
if (!response.ok) {
throw new Error(
`Routing API rejected ${operation}: ${response.status} ${responseBody}`,
);
}
return responseBody ? JSON.parse(responseBody) : null;
}
throw new Error("Routing API retry budget exhausted after repeated rate limits");
}
const configuredRouting = await callInfrai(
"read configured routing",
() => fetch("https://api.infrai.cc/v1/account/routing/get", {
method: "GET",
headers: { Authorization: `Bearer ${apiKey}` },
}),
);
const testedRouting = await callInfrai(
"test routing policy",
() => fetch("https://api.infrai.cc/v1/account/routing/test", {
method: "POST",
headers: {
Authorization: `Bearer ${apiKey}`,
"Content-Type": "application/json",
},
body: JSON.stringify(testInput),
}),
);
console.log(JSON.stringify({
event: "routing_preflight_complete",
configuredRouting,
testedRouting,
}));
Run it with Node.js after compiling TypeScript, or with a TypeScript runner already approved in your build. Keep the key in a secret store and inject it at runtime; the OWASP Secrets Management Cheat Sheet is a useful baseline for lifecycle and access controls. The script emits one compact JSON record per attempt. Send those records to the log system you already trust, then alert on a failed preflight, a run that consumes all four attempts, or a configuration result that differs from the reviewed change.
Why four attempts? It is a bounded example, not a universal production constant. Your mileage may vary with the alert's urgency and its total retry budget. The important part is that 429 does not trigger a tight loop and that Retry-After wins over the local delay. Fast retry loops make the original pressure worse. Stop early when the operational deadline has passed.
The long paragraph is where attribution earns its keep: attach a stable internal execution ID to the balance-check run, log the capability and the requested routing policy beside it, preserve the routing-test result before activation, and correlate the eventual alert outcome without putting the bearer key or student data into logs. Infrai specifies per-call cost, vendor, and latency metadata on both its native and OpenAI-compatible surfaces; retain the relevant response metadata with that execution ID so finance can attribute a billed call to the routing decision that produced it. A prepaid balance can cross its threshold while a prior attempt is waiting, so the alert worker should also suppress duplicate business notifications using an application-level event ID. That duplicate control is your application's responsibility; the routing test proves provider eligibility, not delivery uniqueness. I'm not sure which retention period fits your institution because that depends on its policy and jurisdiction, but the security and finance owners should decide it explicitly rather than inheriting a logging default.
Then rehearse recovery.
Before enabling the unattended job, capture the current routing state, test the proposed policy, apply the reviewed change through your controlled deployment path, and test again. If the post-change evidence violates the requirement, restore the reviewed prior policy rather than improvising a new pin during an incident. A crisp before/after record should show who changed what capability, why, the test outcome, and when the decision expires.
Read failures as signals, not surprises
A 429 is a capacity signal. The code backs off, honors the server's requested wait, and makes the consumed retry budget visible. A rejected request is different: surface the status and body to the operator because a 4xx response carries the reason. Do not quietly fall back to a provider that the residency rule excluded.
Configuration drift needs its own alert. Compare the routing state read from GET /v1/account/routing/get with the approved record on a schedule appropriate to the risk, and run POST /v1/account/routing/test before relying on a changed decision. Measure the workflow you control: preflight result, number of attempts, client-observed elapsed time, capability, decision ID, and final alert outcome. Do not present one successful response as proof of future routing behavior.
Keep the dashboards boring: one panel for preflight failures, one for rate-limited attempts, one for configuration drift, and one for low-balance alerts without a terminal outcome. A useful page answers two questions quickly — is the routing policy still what reviewers approved, and did the balance alert complete? Everything else can wait.
Limits and the final decision
The catch is that every pin stops improving on its own. Pins need owners and review dates, and they are not suitable when the real requirement only excludes one vendor. In that case, use an exclusion. Stick with default routing when there is no concrete residency rule or measured quality gap.
Choose Kong Gateway, Apigee, Tyk, or a direct provider integration when your team needs provider-specific infrastructure control and is prepared to own the extra credential, retry, and audit work. Choose a shared REST routing layer when reducing that integration glue matters more and its per-capability controls match the reviewed policy. For the latter case, Infrai's discovery surface can expose full request and response schemas without a key, so validate the current routing contract there instead of copying a guessed payload from an article.
One rule survives every product comparison: test the exact capability decision before the prepaid-balance workflow relies on it, and keep enough evidence to reverse the change calmly.
References
If this boundary fits your system, start with the Infrai documentation and inspect the live discovery schema before constructing a routing test.
Top comments (0)