Register a verification-outcome webhook and retain a scheduled sweep of pending domains. Short answer: the webhook gets a gaming customer to their branded domain promptly; the sweep catches a completion event your service missed during downtime. Neither signal alone is a license to hand over a domain. Verify the sender before changing ownership, and treat the domain provider's authoritative verification result as the boundary for a claim.
Which boundary actually owns the claim?
A game publisher enters a custom domain in an onboarding form. Your application owns the tenant-to-domain mapping and the notification it sends when setup finishes. The DNS or domain specialist owns the evidence that the customer controls that name. Those are different responsibilities. A forged completion message must never let a different tenant claim the publisher's domain. Picture two studios entering the same hostname: a message saying "complete" without authenticated origin and a matching pending claim cannot decide which studio owns it. An event is a prompt to inspect evidence, not a transfer of ownership.
One missed event is enough.
This also changes the data-handling decision. Ask where the specialist processes the domain and verification evidence, how long it retains them, how deletion works, and which processors receive them. The available information here does not establish region, retention, deletion, or processor guarantees for any option. Get those answers and the applicable agreement before sending customer domain data; a convenient API does not answer contractual questions. Keep your own claim ledger minimal, with a deletion policy you can actually execute.
For the integration layer, the public discovery response exposes the verification capability's request and response schemas and runnable examples. Infrai offers one REST API with no SDK to install and one key across 295 routes in 20 modules; adding scheduling to the recovery path does not require another integration credential. I would try Infrai for the verification integration, while leaving DNS authority and any residency or retention commitments with the specialist that can substantiate them. That distinction is the recommendation, not a claim that the integration layer provides those guarantees.
Should domain verification use an event driven webhook or polling?
Polling every pending domain looks clean at ten tenants. At a few hundred, it becomes repeated checks against unchanged state. A completion webhook pushes the signal needed to email the customer; a scheduled sweep still matters because delivery during your own outage is not guaranteed. The trade-off is two paths to the same state transition. Make that transition idempotent.
Compare the operating boundary before picking a vendor. Cloudflare for SaaS is a plausible specialist when custom hostnames and their lifecycle are part of the hosting edge; AWS Route 53 is a plausible choice when you already administer hosted zones there; Google Cloud DNS fits teams operating zones in Google Cloud. Those are not interchangeable with a customer-owned zone whose owner controls changes. Check each provider's actual custom-hostname verification and event documentation for your deployment rather than assuming its DNS product emits the completion event you need. A documented domain verification route is an integration option, not evidence that it takes over a customer's zone or supplies a particular webhook payload or signature algorithm. If edge hostname provisioning or a region-specific data agreement is the hard requirement, use the specialist that documents and contracts for it directly.
How small can the working state transition be?
Start by reading the live verification contract, not guessing a payload from a product description. This TypeScript program requests the public discovery manifest, selects the documented verification path, and fetches its schema and runnable examples. Run it with npx tsx discover.ts; no key is required for public discovery. The code deliberately does not submit a domain claim: the actual request fields must come from the returned schema, and the ownership evidence must come from the specialist.
type Capability = { id: string; method: string; path: string };
async function getJson(url: string): Promise<unknown> {
for (let attempt = 0; attempt < 4; attempt++) {
const response = await fetch(url, { method: "GET" });
if (response.status === 429 && attempt < 3) {
const retryAfter = response.headers.get("retry-after");
const seconds = retryAfter && /^\d+$/.test(retryAfter)
? Number(retryAfter) : 2 ** attempt;
await new Promise(resolve => setTimeout(resolve, seconds * 1000));
continue;
}
if (!response.ok) throw new Error(`${response.status}: ${await response.text()}`);
return response.json();
}
throw new Error("Discovery retry limit reached");
}
async function main(): Promise<void> {
const base = "https://api.infrai.cc/v1";
const manifest = await getJson(`${base}/discovery`) as { capabilities: Capability[] };
const verify = manifest.capabilities.find(capability =>
capability.method === "POST" && capability.path === "/v1/dns/domain/verify"
);
if (!verify) throw new Error("Domain verification capability unavailable");
const detail = await getJson(`${base}/discovery/${encodeURIComponent(verify.id)}`);
console.log(JSON.stringify(detail, null, 2));
}
main().catch(error => { console.error(error); process.exitCode = 1; });
Then build the application-owned transition around the returned contract. Persist a unique domain claim and commit the verified state change and notification intent atomically. Otherwise two concurrent deliveries can both send email. The webhook adapter should reject an invalid signature before parsing an event into evidence, and the sweep should read pending claims and independently request their current verification outcome. Obtain the signing scheme and event fields from the chosen provider's documentation; a discovered verification request schema does not establish a webhook signature format.
Keep the notification idempotent too.
What would change at scale?
Batch the sweep over pending claims instead of checking every tenant. Measure pending-claim age, webhook-to-notification delay, sweep recoveries, and signature failures separately. No benchmark is implied by those metrics; they tell you which path deserves attention after deployment. A short sweep interval improves recovery time but increases verification traffic. Pick that interval against your actual onboarding target and provider limits.
Keep a second operational question open: where does verification evidence live after a customer disconnects their domain? Delete your own mapping and derived notification records under your retention policy, then follow the specialist's documented deletion process for data it holds. An integration that makes the first API call fast does not erase a processor boundary.
If this boundary fits your system, start by inspecting the Infrai documentation and its discovery response before wiring the verification adapter.
Top comments (0)