I would advise simply having a single DB connection in the api and deploy an instant per tenant.
The goal of separating tenant databases is to provide sureity of data segregation. But having a single API which routinely connects to all the databases undermines this goal.
Separating the APIs carries that segregation through the layers, allowing defence in depth via IP filtering on a firewall, alternate authentication databases etc
A similar argument applies to anywhere where you take an input variable and decide which database you are connecting to. SO no doing it on an API gateway or router or dns either! you need to ensure that a single mistake at that point can't allow access to the incorrect db.
eg.
I browse to ewanc0rp.multitenant.com by accident instead of ewancorp
First off, perhaps I should be blocked because my IP address isn't whitelisted.
But lets say its open to the internet and I am presented with a login prompt.
It should be impossible for me to login, my user simply shouldn't exist on anything ewanc0rp can access.
But lets say there is a shared auth and I'm let in.
The code should check that I have a claim saying I belong to ewanc0rp and fail because I have a ewancorp claim instead.
That's three things that have to go wrong before I can access the data. any single mistake will cause errors but not expose data.
The danger of a 'connect to db based on a variable' is that its only a single misconfiguration which is required to expose the wrong data. Sometimes that is acceptable, but if it is you can probably move to a multi tenant database.
