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 once its settings give it apiAccessType: TOKEN_ACCESS (the token of an API user whose group grants this system API, in x-am-authorization) or IS_PUBLIC. Without settings it is NO_ACCESS : your code calls it through g.sys, the admin panel tests it, and an HTTP call is refused.
The settings can also cache the answer or require person tokens (authProviders) ; pre and post hooks run around it like around any API.
The request headers apply : x-am-response-case, x-am-content-type-response, x-am-internationalization, x-am-tenant-username…