Call it when the connection string of a tenant of a multi-tenant instance changes in the tenants table : every server drops the connection pools of that tenant and the cached answers of the instance and of the tenants table, so the next request of the tenant reads its row again and connects to the new database.
Method
POST
URL
/api/system-api/admin/multi-tenant-instance-updated : admin is the user path of your account
{"success":true,"statusCode":200,"data":[{"success":true,"data":true},{"success":false,"data":false,"error":{"code":400,"message":"Instance 'billing' is not a multi tenant structure instance."}}]}
Each item is answered on its own : an unknown instance (404) or an instance which is not multi-tenant (400) does not stop the other items.
Both fields are required.
Until this API is called, the servers keep using the pools they have. For PostgreSQL, the pools of every database of the tenant are dropped.
Over HTTP, a system API answers only once its settings open it : TOKEN_ACCESS (the token of an API user whose group grants this system API) or IS_PUBLIC. Without settings it is NO_ACCESS : only your code (g.sys) and the admin panel reach it.
The settings can also keep the answer in the cache, or ask for the token of a person (authProviders). Pre and post hooks run around it, as around any API.
It takes the request headers and answers the envelope. 401 : no valid token, or the API is NO_ACCESS. 403 : no group grants it. 400 : the body is wrong, and the message names the key.