Feature Request: Support wildcard subdomains in domain allowlist

[serialx]

When deploying ChatKit in non-development environments, we're required to add our domains to OpenAI's domain allowlist. However, the current allowlist implementation doesn't support wildcard subdomain patterns (e.g., *.example.com), which creates significant friction for modern deployment workflows.

Problem

Many teams use deployment platforms that generate dynamic subdomains for preview/staging environments:

• Vercel: my-app-<hash>-<team>.vercel.app or my-app-git-<branch>-<team>.vercel.app
• Netlify: deploy-preview-<number>--<site>.netlify.app
• Custom CI/CD: Internal preview deployments like myapp-pr-123.preview.company.com

Since these URLs are generated dynamically per commit/PR, it's impossible to pre-register them in the allowlist. This effectively means:

1. ChatKit cannot be tested in preview deployments before merging to production
2. Teams with dynamic internal deployment systems cannot use ChatKit at all
3. Every new preview environment requires manual allowlist updates, which defeats the purpose of automated deployments

Proposed Solution

Support wildcard patterns in the domain allowlist:

*.vercel.app
my-app-*.vercel.app  # better!
*.preview.mycompany.com
myapp-pr-*.preview.mycompany.com  # better!

Alternatively, provide a way to:

• Allowlist by project/team identifier rather than exact domain
• Support regex patterns for more flexible matching
• Offer a "preview mode" token with relaxed domain restrictions for non-production use

Impact

This limitation blocks adoption for teams that rely on preview deployments as part of their development workflow, which is increasingly standard practice.

[tylersmith-openai]

Broad subdomain support is already present.

• If you add vercel.app, for example, all subdomains of that top-level domain are allowed.
• Similarly, if you add preview.mycompany.com, all subdomains of that subdomain path are also allowed.

Adding support for regex does helpful here, though - we'll look into it! In the meantime, hopefully that helps clarify how domain declarations work so that you can unblock to some degree.

[serialx]

I did some tests and subdomain support seems to not work.

• I've added example.com (This is obviously just for security reasons, I've actually added my production domain name instead of example.com when doing the actual testing)
• Subdomain verification fails. eg. a.example.com

$ curl 'https://api.openai.com/v1/chatkit/domain_keys/verify' --json '{"referrer_origin":"https://a.example.com","domain_key":"domain_pk_xxxx"}'
{
  "dev_local_warning": null,
  "verified": false
}

$ curl 'https://api.openai.com/v1/chatkit/domain_keys/verify' --json '{"referrer_origin":"https://example.com","domain_key":"domain_pk_xxxx"}'
{
  "dev_local_warning": null,
  "verified": true
}

[tylersmith-openai]

I'm not 100% sure what's incorrect with your cURL snippets, but what I described is how this works.

Try copying the cURL snippet straight out of DevTools, then appending a subdomain to the referrer_origin. I just verified this, and then verified a failure by changing the top-level domain.

[serialx]

I've actually did copy the cURL snippet straight out of DevTools. Just trimmed down the unnecessary headers so you can read it better. Here's one that is actual deployed key and tested domain (test.devschoco.cloud). You can copy paste it and test it.

$ curl 'https://api.openai.com/v1/chatkit/domain_keys/verify' --json '{"referrer_origin":"https://test.devschoco.cloud","domain_key":"domain_pk_69782b931cb88194a25aa0f0662c038c0218d4015076e6ff"}'
{
  "dev_local_warning": null,
  "verified": true
}

$ curl 'https://api.openai.com/v1/chatkit/domain_keys/verify' --json '{"referrer_origin":"https://x.test.devschoco.cloud","domain_key":"domain_pk_69782b931cb88194a25aa0f0662c038c0218d4015076e6ff"}'
{
  "dev_local_warning": null,
  "verified": false
}

[tylersmith-openai]

Okay, thank you! I see the issue now. It looks like our subdomain permissiveness is not correctly allowing your subdomain definitions to reach other additional subdomains as expected.

I suspect your domain key is scoped to test.devschoco.cloud - I just verified the failure on my end with declaring a key specifically at test.chatkit.studio, then trying an example foo.test.chatkit.studio domain.

For a temporary workaround, if you set your key to devschoco.cloud, all subdomains will work as expected.

We'll follow-up when this is fixed.