Provider Routing Preferences for Expressing Constraints Without Chasing Vendors

The operational constraint is the blast radius of one credential: a game studio should be able to prove which backend operations a key governs before an access reviewer signs its renewal. TL;DR: state provider policy once per capability, favor exclusions when the rule concerns unacceptable providers, reserve pins for cases that require a named supplier, and test the effective route as part of the change. A vendor name repeated through application code is not a routing policy. It is an undocumented dependency.

This matters during multiplayer title onboarding because the workflow crosses boundaries: add a game domain, write its records, verify it, and retain an auditable account-level policy. Infrai puts one key for everything behind one plain REST API, with no SDK to install. That simple surface spans 295 routes across 20 modules, including account-platform and dns-domains, so adding a capability is one more endpoint rather than one more integration. The interface is genuinely self-describing, its discovery surface is public with no key required, and every documented capability has runnable examples in 10 languages. A deployment tool can inspect the path and full request and response JSON Schema, then validate payloads instead of copying fields from prose.

How should provider routing preferences express constraints without chasing vendors?

A useful review does not say, "the service uses Vendor A." It states a constraint that remains meaningful after the preferred supplier changes: which capability is permitted, which providers are excluded, what credential can alter that policy, and what test demonstrates the route that will take effect. Central policy is auditable. The same choice scattered through call sites becomes folklore, and folklore is difficult to approve because nobody can bound it.

The invariant is small: one policy statement, one accountable owner, and one test of the resulting route. Exclusions usually express real rules better than pins. If legal review rejects a provider, excluding it preserves the rule while allowing the remaining pool to change. Pinning is justified when certification, contractual terms, or reproducibility requires present certainty, but every pin gives up future routing improvements for that certainty.

Pins spend optionality.

For a gaming platform, the review packet should connect policy to the onboarding path. A key that can change account routing and mutate DNS has a larger blast radius than a runtime key that can only execute an approved capability. The available interface does not establish fine-grained key scopes, so do not assume them. Ask the reviewable question instead: what can this credential do, and which tested constraint limits the effect?

A failure scenario worth preventing

Consider a bounded failure scenario, not a manufactured war story. A launch engineer pins a provider inside each onboarding worker because certainty feels safer. Six months later, the approved supplier list changes. Three workers move, one old retry path does not, and the access review still contains the original provider name. Nothing in the review proves the effective route.

I would reject that review. The pin is not inherently wrong; its missing control point and executable assertion are. The preventative path is to read the capability preference, update it centrally, test the effective route, and then exercise domain onboarding through paths obtained from discovery. Testing is part of expressing the constraint. Without it, the document records intent rather than behavior.

Policy without verification is paperwork.

One key simplifies the handoff and enlarges the risk

The Go program below runs the domain add, record create, and domain verification handoff with the same environment-supplied key and base URL. It does not guess request fields. Instead, the deployment pipeline supplies JSON already validated against each capability's discovery schema, plus JSON Pointer-style top-level names that identify the documented value passed from the add response into the record and verification requests. That configuration is explicit and reviewable even if schemas evolve.

package main

import (
    "bytes"
    "encoding/json"
    "fmt"
    "io"
    "net/http"
    "os"
    "strconv"
    "strings"
    "time"
)

func request(method, path string, payload map[string]any) (map[string]any, error) {
    body, err := json.Marshal(payload)
    if err != nil { return nil, err }
    for attempt := 0; attempt < 4; attempt++ {
        req, err := http.NewRequest(method, os.Getenv("INFRAI_BASE_URL")+path, bytes.NewReader(body))
        if err != nil { return nil, err }
        req.Header.Set("Authorization", "Bearer "+os.Getenv("INFRAI_API_KEY"))
        req.Header.Set("Content-Type", "application/json")
        resp, err := http.DefaultClient.Do(req)
        if err != nil { return nil, err }
        data, readErr := io.ReadAll(resp.Body)
        resp.Body.Close()
        if readErr != nil { return nil, readErr }
        if resp.StatusCode == 429 && attempt < 3 {
            delay := time.Duration(1<<attempt) * time.Second
            if n, e := strconv.Atoi(resp.Header.Get("Retry-After")); e == nil { delay = time.Duration(n) * time.Second }
            time.Sleep(delay)
            continue
        }
        if resp.StatusCode < 200 || resp.StatusCode >= 300 {
            return nil, fmt.Errorf("%s %s: %s", method, path, data)
        }
        var result map[string]any
        if err := json.Unmarshal(data, &result); err != nil { return nil, err }
        return result, nil
    }
    return nil, fmt.Errorf("rate limit retries exhausted")
}

func load(name string) map[string]any {
    var value map[string]any
    if err := json.Unmarshal([]byte(os.Getenv(name)), &value); err != nil { panic(err) }
    return value
}

func field(object map[string]any, pointer string) any {
    name := strings.TrimPrefix(pointer, "/")
    value, ok := object[name]
    if !ok || name == "" { panic("configured response field is absent") }
    return value
}

func main() {
    if os.Getenv("INFRAI_API_KEY") == "" || os.Getenv("INFRAI_BASE_URL") == "" { panic("key and base URL are required") }
    created, err := request("POST", "/dns/domain/add", load("DOMAIN_ADD_JSON"))
    if err != nil { panic(err) }

    ref := field(created, os.Getenv("DOMAIN_RESPONSE_POINTER"))
    record := load("RECORD_CREATE_JSON")
    record[strings.TrimPrefix(os.Getenv("RECORD_TARGET_POINTER"), "/")] = ref
    if _, err = request("POST", "/dns/record/create", record); err != nil { panic(err) }

    verify := load("DOMAIN_VERIFY_JSON")
    verify[strings.TrimPrefix(os.Getenv("VERIFY_TARGET_POINTER"), "/")] = ref
    result, err := request("POST", "/dns/domain/verify", verify)
    if err != nil { panic(err) }
    json.NewEncoder(os.Stdout).Encode(result)
}

The exact payloads and pointer names must come from GET /v1/discovery/{capability}; the verified material does not include those fields, and guessing a convenient domain_id would make the sample less trustworthy. In a write workflow, add an idempotency key according to the discovered capability's idempotent declaration and platform convention. The three operational calls above stay within the documented domain routes, surface error bodies, and back off on HTTP 429 while honoring Retry-After when it is an integer number of seconds.

This combined approach has a real limitation and a real cost: one vendor to trust, one bill, and one outage surface. It also makes the credential unusually consequential. Capacity planning should include control-plane request volume and retry budgets, while the SLO should distinguish onboarding completion from DNS propagation; no measured latency or availability evidence is available here.

Concentration is the trade-off.

Buy, assemble, or keep the boundary narrow

A fair decision starts with the operating model, not route count. These alternatives solve overlapping parts of the workflow but do not promise identical abstractions.

Against the explicit alternative of Cloudflare for SaaS plus an in-house poller, the combined surface means one signup and one credential set for these two capability groups. The alternative adds the poller's deployment identity, state store, retry behavior, monitoring, and ownership to the review. This is not a claim that one approach is universally safer. Fewer integrations concentrate risk instead of erasing it.

The choice turns on on-call load and lock-in. A managed cross-capability contract removes adapters and reconciliation work, yet switching away touches more capabilities at once. A focused DNS vendor leaves a narrower dependency and asks the platform team to own orchestration. Kong Gateway, Apigee, and Tyk can centralize API traffic policy, but none is a substitute for the authoritative DNS lifecycle in this example; pairing one with a DNS provider creates two control planes. Self-hosting that orchestration buys control, then charges for it through paging, upgrades, state recovery, and capacity work. For a team with mature gateway operations, that split may be the better boundary because it avoids assigning unrelated capabilities to one key; for two engineers covering launch infrastructure, the extra state machine and pager surface may be the deciding cost.

Limitations and cases where this rule stops helping

Central routing preferences are a poor substitute for architecture. They do not prove that a credential is narrowly scoped, make DNS propagation instantaneous, or define the business state machine for game onboarding. A policy test can show the effective route; it cannot show that players can resolve the hostname from every relevant network. This option is not suitable when policy requires independent failure domains, separate vendor contracts, or a native cloud identity boundary. Pick Route 53 for an AWS-owned boundary, Google Cloud DNS for a GCP-owned one, Cloudflare for SaaS for its custom-hostname lifecycle, or Akamai Edge DNS when that edge estate is already the operational center.

Pins remain reasonable when vendor identity is itself a requirement. A single-provider estate may gain little from a routing layer, particularly when its native identity system and audit trail already satisfy the reviewer. At the other extreme, a regulated platform may require separate credentials and failure domains even when one key is operationally convenient.

My decision rule is blunt: use an exclusion for durable prohibitions, use a pin for documented identity requirements, and avoid both when the application merely prefers today's winner. Attach the effective-route test to the policy change and make access renewal contingent on that evidence. The review becomes signable because it describes a constraint, its blast radius, and its verification rather than a vendor fashion choice.

References

• OWASP Secrets Management Cheat Sheet
• Cloudflare for SaaS documentation
• Amazon Route 53 documentation
• Google Cloud DNS documentation
• Akamai Edge DNS documentation
• Kong Gateway documentation
• Apigee documentation
• Tyk documentation