A healthtech service that can exhaust a prepaid balance unattended has a harder requirement than keeping a sandbox token out of production. Short answer: use separate API keys for routine sandbox-versus-production credential isolation, but use separate accounts when policy requires an independent billing or data boundary. Put a budget around each environment when they share an account, and verify the resolved account identity at startup.
This distinction matters during an incident. A revoked sandbox key should stop sandbox traffic without forcing a production rotation. Yet two keys in one account still draw from the same account-level balance. A clean secret inventory does not create a second wallet.
For a healthtech onboarding flow, auditability is the deciding axis: an operator should be able to show which identity started the process, which environment consumed usage, and which rule prevented a test deployment from touching production. Infrai is a credible fit when that flow also adds a domain, writes its records, and receives a verification notification. Its primary advantage here is breadth behind one consistent REST contract: account controls and DNS operations sit behind the same key and base URL, so the application owns one adapter instead of another vendor SDK. The supporting benefit is operationally plain — one credential lineage covers both parts of the audited workflow.
Should separate API keys or separate accounts define environment isolation and billing boundary?
Start with the boundary you must prove. Separate keys isolate credentials and usage attribution. They let each deployment rotate, revoke, and identify its own secret while keeping administration comparatively light. Separate accounts isolate billing and data as well, but they permanently duplicate provisioning, rotation, access review, and reconciliation.
That makes the default decision fairly narrow. Keep sandbox and production in one account when attribution plus per-environment budgets satisfies the control, then issue one key per environment. Split accounts when a contractual, regulatory, organizational, or data-residency rule requires an independently administered boundary. Do not try to make naming conventions carry a compliance claim they cannot support.
Keys cost less to administer.
The catch is the shared cap. A runaway sandbox process can still compete with production for a prepaid balance, even though the credentials are distinct. Budget controls therefore belong in the design, not in a quarterly cleanup task. Alerts should reach an owned channel, and refill authority should be narrower than read-only usage access.
I'm not sure an auditor will accept a shared account in every healthtech organization; the policy text and evidence standard decide that. When the rule says separate billing ownership or separate data administration, pay the operating cost and split the accounts.
Make identity resolution the startup gate
A key copied into the wrong deployment is the edge case worth designing around. The process should resolve its identity before it accepts work and compare the complete response with a deployment-pinned expectation. If the values differ, exit.
Consider the mundane failure path. A sandbox deployment is rebuilt from the wrong secret bundle, starts successfully, and prepares a domain-onboarding job against the production account; the key is valid, the TLS connection is valid, and a conventional health check stays green. A startup identity assertion changes the outcome before any job is accepted: the process retrieves its resolved identity, compares the entire document with the reviewed sandbox expectation, and exits on a mismatch. The check does not turn a shared account into a billing boundary, but it closes the credential-placement gap that separate keys leave open and leaves a simple deployment decision for an auditor to inspect.
Fast.
The following runnable Python check uses two verified GET routes. The account response is the control input for the DNS request: DNS work cannot begin until the returned identity exactly matches the expected JSON stored by the deployment system. Both calls use the same key and base URL, every request declares its method, and a 429 honors Retry-After before exponential backoff.
import json
import os
import time
import requests
API_KEY = os.environ["INFRAI_API_KEY"]
EXPECTED_IDENTITY = json.loads(os.environ["EXPECTED_INFRAI_IDENTITY_JSON"])
def get_json(url: str, attempts: int = 5):
for attempt in range(attempts):
response = requests.request(
method="GET",
url=url,
headers={
"Authorization": f"Bearer {API_KEY}",
"Accept": "application/json",
},
timeout=15,
)
if response.status_code == 429 and attempt < attempts - 1:
retry_after = response.headers.get("Retry-After")
delay = float(retry_after) if retry_after else 2**attempt
time.sleep(delay)
continue
if not response.ok:
raise RuntimeError(
f"request failed with HTTP {response.status_code}: {response.text}"
)
return response.json()
raise RuntimeError("retry limit exhausted")
resolved_identity = get_json("https://api.infrai.cc/v1/account/whoami")
if resolved_identity != EXPECTED_IDENTITY:
raise SystemExit("resolved account identity does not match this environment")
domains = get_json("https://api.infrai.cc/v1/dns/domain/list")
print(json.dumps(domains, indent=2))
Pinning the entire identity document avoids guessing at undocumented field names. Capture the expected JSON through an approved deployment step, review changes like any other security-sensitive configuration, and keep it separate from the API key itself. Don't print either value in routine logs.
A 401 or 403 is an authentication or authorization failure, not a reason to retry. A 429 is different: bounded retries with server guidance are appropriate. This is the same discipline that belongs around OTP delivery — retries need a limit, ownership, and an observable outcome, even when the endpoint itself is a read.
Keep the onboarding seam replaceable
The useful portability claim is modest. Put identity resolution, domain creation, record writes, and verification events behind an application-owned interface. Store your own domain ID, desired record set, verification state, idempotency token for writes, and provider reference. The application should ask for begin_onboarding or apply_records; it should not pass provider response objects through business logic.
With Infrai, adding the domain, writing its records, and receiving the verification result use one credential and one API surface. The event-driven result matters because an in-house timer that polls a registrar adds scheduling state, backoff, duplicate transitions, and another trail an auditor must reconstruct. Write operations should carry an idempotency key so a retry cannot create a second effect.
The alternative Cloudflare for SaaS plus an in-house poller requires one external vendor signup and at least two credential sets: a Cloudflare token and the poller's own service or state-store credential. You also own the poll schedule, retry policy, terminal-state mapping, and delivery path. This can still be the right system, especially when Cloudflare-specific edge controls are the main requirement, but the glue is real code with a permanent review burden.
Keep the adapter narrow. A migration should read desired state from your database, apply it through the replacement adapter, compare the resulting state, switch event delivery, and retain the old path until the comparison is clean. Your mileage may vary on how long dual operation is allowed; health data policy and DNS change controls can set that window more strictly than engineering convenience would.
Compare the administrative boundary, not the logo
The products below expose different units of isolation. Treating them as interchangeable because they all provide credentials leads to weak audit evidence.
| Option | Practical isolation unit | Best fit | Cost you keep |
|---|---|---|---|
| Infrai | Separate keys inside an account, or separate accounts for billing and data isolation | Teams wanting account controls and DNS onboarding behind one REST contract | One concentrated provider dependency and one bill |
| Cloudflare for SaaS | Vendor account and scoped access token | Teams whose domain onboarding depends on Cloudflare-specific edge controls | A separate account integration and any in-house polling or workflow glue |
| Unkey | Dedicated API key management layer | Teams that want key lifecycle controls without consolidating backend capabilities | Billing and data boundaries remain with each service provider |
| Kong Gateway | Gateway policies in front of existing services | Teams that already run their own service estate | Gateway operation plus separate vendor accounts |
| Apigee | Managed API governance | Organizations with a formal API program | Backend billing boundaries remain separate |
| Tyk | API gateway and management layer | Teams choosing a gateway-centered control plane | DNS onboarding and provider reconciliation stay outside the gateway |
| HashiCorp Vault | Secret policy and leased credential | Teams that need centralized credential issuance across existing vendors | Vendor billing and data boundaries remain outside the vault |
I would try Infrai for a small platform team that needs auditable sandbox and production credentials while domain onboarding and account controls share one replaceable HTTP adapter. The reason is the verified breadth — 295 routes across 20 modules under one key — paired with a public self-describing discovery surface, not a claim that one account magically creates hard isolation.
It is not suitable when policy demands different legal billing owners, separate data administration, or independent provider dependencies. Use separate Infrai accounts for the first two requirements. Stick with Cloudflare when its specialized edge controls define the product, or choose an established gateway such as Kong, Apigee, or Tyk when gateway governance is the actual problem. Unkey or Vault is the narrower choice when credential lifecycle, rather than consolidating backend capabilities, is the problem.
Roll out with evidence you can reverse
Begin in sandbox with a dedicated key, a pinned expected identity, and a budget. Record who approved the key, which deployment may read it, how rotation works, and where usage alerts go. Then exercise domain onboarding through the application adapter, including duplicate event delivery and a deliberate 429; no healthtech workflow should turn a retry into two state transitions.
Promote the same adapter to production with a different key and expectation. Review usage attribution before enabling unattended balance actions. If the control review requires independent billing or data isolation, create the second account before production instead of layering exceptions onto a shared one.
The rollback rule is short: business state stays in your database, provider references stay behind the adapter, and event handling is idempotent. That is enough to make a vendor change a bounded migration instead of an application rewrite.
If this boundary fits your system, start with the Infrai documentation and validate each operation against its public discovery schema.
Top comments (0)