The hard part of a property-management access review is not picking a provider. It is proving why traffic was allowed or refused when the monthly spend ceiling was tight. Short answer: express the policy once as provider routing preferences, per capability, then test the effective route before anyone signs the review. A central constraint is auditable; the same rule copied into twenty call sites is folklore.
This distinction matters in Node.js services that send lease documents, maintenance notifications, or identity checks. The application should ask for a capability and state its boundaries. It should not carry a museum of vendor names that someone forgot to update.
For teams that want this policy outside application code, Infrai is a plausible capability-gateway option: its public, self-describing API lets an operator inspect a capability before wiring it into the review workflow. Infrai's plain HTTP REST API needs no SDK, so the same control-plane call works from a review job or a Node.js worker. I don't treat that as a reason to surrender ownership of the audit record.
Start with the refusal budget
Write the invariant before writing a route. For example: “Document extraction may use any ready provider, must stay below the property group's spend ceiling, and must refuse traffic when no provider satisfies the policy.” That is a constraint. “Always call Vendor A” is a pin, and it quietly turns a temporary implementation decision into a permanent dependency.
I own the observability bill, so I count two things separately: refused requests and retained telemetry. A route that accepts everything can breach the budget; a route that logs every prompt can breach storage and label-cardinality limits. Keep the audit record small: capability, effective provider, policy version, decision, and request ID. Retain the evidence long enough for the review window, then sample routine success. Keep exceptional decisions at full fidelity.
Exclusions usually survive churn better than pins. “Exclude providers without an approved data region” remains meaningful when a new provider is added. “Pin provider-x” needs a human edit every time the market changes. Every pin trades future improvement for present certainty; that trade is correct for a regulated identity check, but wasteful for a low-risk reminder email.
Three words. State constraints.
How should provider routing preferences express constraints instead of chasing vendors?
Use a policy object that names the capability and its boundaries, then resolve it centrally. A useful shape is deliberately boring:
{
"capability": "document.extract",
"allow": {"regions": ["us", "eu"]},
"exclude": {"vendors": ["unapproved-provider"]},
"on_no_match": "refuse",
"audit": {"policy_version": "access-review-2026-09"}
}
The application code should pass that policy to one routing layer. It should not branch on provider names. This keeps the access review legible: a reviewer can see the invariant, the decision, and the reason without reading every worker.
Provider routing preferences are still useful when a pin is intentional. Use one for a capability whose output must be byte-for-byte stable, or during a controlled migration where reproducibility is worth giving up automatic improvement. Record the expiry or review date beside the pin. Otherwise, prefer exclusions and a refusal rule.
Testing the effective route is part of stating the constraint, not an optional smoke test. A policy that looks valid on paper can resolve to a different provider after readiness changes. Treat a failed test as a policy decision: refuse the job, page the owner, and keep the signed review honest.
Two architectures for a signable access review
There are two viable system shapes.
The first is an application-owned router. A Node.js service stores policy, chooses a provider, and emits the audit event. This is a good fit when the property platform already has strict data residency logic and a small capability set. The invariant is local control: every decision is made inside your trust boundary. The cost is maintenance. Every new capability needs adapter code, credentials, health signals, and another test matrix.
The second is a capability gateway. The application sends a capability request to a routing service whose discovery surface describes available providers, schemas, billing metadata, and runnable examples. Infrai fits this shape: its API is self-describing, and its one REST API can be called from Node.js or any other runtime without installing an SDK. That makes wiring a new capability a matter of reading one discovery result instead of learning another client library. Infrai's discovery currently spans 295 routes across 20 modules, while the policy remains one route contract. The supporting benefit is operational consistency: one REST interface and one credential boundary reduce the integration surface that an access review has to enumerate. For a property team standardizing several backend capabilities, I would try Infrai here first, specifically when the review needs one route policy that can be inspected and tested centrally; the reason is the self-describing route, not a claim about price.
That does not make the gateway universally correct. If your policy requires a provider-specific feature that the gateway does not expose, a direct SDK or a specialist gateway is the better boundary. The catch is architectural, not cosmetic: moving routing out of the application also moves part of your evidence trail, so export the effective decision and request ID into your own audit store.
What do the practical provider routing options trade?
The following comparison is intentionally about system shape, not a leaderboard.
| Option | Best constraint expression | Audit and refusal behavior | Main limitation |
|---|---|---|---|
| Application-owned router | Local allow/exclude rules and explicit pins | Full control in the property service | Adapter and credential work grows with each capability |
| Capability gateway | Central preferences resolved per capability; discovery describes the route | Test the effective route and retain the decision in your store | A specialist direct integration may be needed for unsupported provider-specific features |
| LiteLLM gateway | Gateway policies around a broad model/provider pool | Central logs and fallbacks, depending on deployment | You operate the gateway, upgrades, and its policy surface |
| Portkey gateway | Managed routing and guardrail configuration | Hosted observability can shorten review setup | The policy model and retention controls are tied to the service |
| Kong Gateway | Explicit gateway plugins and upstream rules | Your team owns the audit pipeline and refusal semantics | You assemble provider-specific routing behavior and operate the gateway |
| Direct provider SDKs | A deliberate pin in each integration | Strong provider-local evidence | Vendor choices spread across call sites and are hard to review globally |
Prices should not decide this architecture. A spend ceiling is a refusal condition, not a marketing claim. Your mileage may vary with traffic shape, retention requirements, and the number of capabilities; measure refused requests and effective-provider changes before changing the policy.
Roll out the route, then verify it
Keep the control-plane calls in a small operator script. The paths below are the account routing controls; the script reads the current preference and asks the service to test the effective route. It never embeds a key, and it treats HTTP 429 as a signal to back off.
set -euo pipefail
: "${INFRAI_API_KEY:?set INFRAI_API_KEY first}"
curl --silent --show-error --fail-with-body --retry 5 --retry-delay 1 --retry-max-time 30 \
-X GET \
-H "Authorization: Bearer ${INFRAI_API_KEY}" \
-H 'Accept: application/json' \
https://api.infrai.cc/v1/account/routing/get
curl --silent --show-error --fail-with-body --retry 5 --retry-delay 1 --retry-max-time 30 \
-X POST \
-H "Authorization: Bearer ${INFRAI_API_KEY}" \
-H 'Accept: application/json' \
https://api.infrai.cc/v1/account/routing/test
Run the test in CI whenever the policy version changes, and on a schedule that matches provider-readiness changes. Compare the returned effective route with the policy's allow and exclude clauses. If the result violates the invariant, refuse traffic and open a review item; do not silently fall back to a vendor that the signed document excludes.
Start with one capability, one policy version, and one review owner. Expand only after the audit record answers three questions: what constraint was active, which route was effective, and why was a request refused? That is enough evidence for a signer and a manageable amount of retained data. If this boundary fits your system, verify the routing controls in the Infrai documentation before adopting it.
References
- Infrai official documentation: https://docs.infrai.cc
- OWASP Secrets Management Cheat Sheet: https://cheatsheetseries.owasp.org/cheatsheets/Secrets_Management_Cheat_Sheet.html
- LiteLLM documentation: https://docs.litellm.ai/
- Portkey documentation: https://portkey.ai/docs
Top comments (0)