Custom domains for gateway routes
Your hostname on TLS, traffic still routed to isolated handlers.
Situation
Why hostnames matter
Branded domains reduce phishing risk and make SDK defaults cleaner.
Some enterprise buyers expect certificate and DNS control in their tenant documentation.
Sharp edges
What goes wrong casually
Hard-coded vendor URLs complicate white-label and multi-tenant stories.
Misconfigured TLS or stale CNAMEs create flaky auth cookie behavior.
How Inquir fits
Gateway alignment
Bring domains through the gateway layer so function routing and TLS termination stay coherent.
Combine with API keys or other auth modes per route as needed.
Capabilities
Operational checklist
DNS
Plan ownership and TTL before cutover windows.
Certificates
Automate renewal where DNS and issuance policies allow.
Multi-tenant
See multi-tenant routing for host-per-customer setups.
Steps
How to attach custom domains to the Inquir gateway
Verify domain
Prove control via DNS records the platform expects.
Map routes
Attach paths or wildcard patterns to target functions.
Monitor
Watch handshake errors and 4xx spikes after go-live.
Code example
Conceptual mapping
Separate DNS proof from application routing concerns.
{ "host": "api.example.com", "routes": [{ "path": "/v1/ingest", "functionId": "ingest" }] }
Fit
Use branded domains when…
When to use
- Customer-facing APIs
- Webhook endpoints partners whitelist
When not to use
- Purely internal tools where default hosts suffice
FAQ
FAQ
Can I use wildcard subdomains for customer APIs?
Capability depends on deployment and certificate automation; confirm wildcard issuance and renewal in your environment before promising it in contracts.
What breaks when DNS or TLS is misconfigured?
Clients see handshake failures or wrong routes; monitor certificate expiry and CNAME health separately from application releases.
How do custom domains relate to webhook URLs?
Partners often whitelist your hostname; a stable api.yourproduct.com is easier to audit than a rotating vendor default.