We have a general pattern of using the subdomain to redirect to different servicing infrastructure underneath, and then path slugs for content we want to be discoverable like guides and docs and important service points like our main query APIs.
the IDs that
@Gwen Shapira mentions are a byproduct of how we built our multi-tenancy - the subdomain identifies which service, and the UUID your tenant. Because we allow instant signup, if we allowed users to specify vanity tenant names a malicious user might hunt for company names that are taken and infer who else is on the platform, so random UUID is easier than solving obfuscation.
We often get asked about vanity domains actually, but it's never high up the customer priority list as they can proxy our APIs behind Apigee etc. which is usually what they care about.
One other thing we do is simplify the URL a customer needs to access our services by combining the auth token with a tenant identity, so the URI construct to query their data is just our base URL for the hosting service + their endpoint name + output format like
https://api.tinybird.co/v0/pipes/my_useful_api.json, then the parameters include the access token and any query parameters.