We are a SaaS observability company. Our architecture has multiple availability zones and multiple tenants within each availability zone, and each tenant have their own API/instance URL.
For example, customer 1234 in Europe may use the domain 1234.eu1.observeinc dot com; customer 4567 in Asia-Pacific might use the domain 4567.ap1.observeinc dot com.
Customers are only known to their particular instance; other instances know nothing about the customer (this is important for data isolation purposes; for example, GDPR prevents some customers from sending some kinds of data outside of Europe.)
There is also a global marketing page at www.observeinc dot com with things like terms of service and privacy policies, as well as requests to talk to our sales organization.
Customers are typically engineers who work on large web sites. When there is an outage, our tool helps debug the systems. Customers will frequently coordinate outages in a tool like Slack, but will often use a separate conferencing system like Zoom for real-time discussion.
We are building a feature to connect to Zoom calls for these incidents, for purposes of doing textual transcription so we can generate technical suggestions using “AI magic.” We’re currently integrating to conferencing services such as Zoom using the service provider recall dot ai.
With all that out of the way, the new Zoom client key requirement is throwing a spanner in the works here, because there appears to be no way to provide a per-app-instance set of URLs, and each URL needs to be validated by the Zoom team.
I believe that we can still make this work if our full set of top-level domains (eu1.observeinc dot com, etc) can be validated, but the web form doesn’t like this, so I now follow the process and ask for help here.
(Also, the “new users can’t post links” check gets in the way … so “dot com” it is!)