Hosting the API
The API is served by the same application as the interface. There is no separate API process to deploy, configure or keep in step.
Where to find it
Architect Panel → Integration & Connections:
- API Server — the settings and the request log
- Deployments — how the application is deployed
Architect Panel → Configuration:
- Site Settings — rate limiting and request logging
Why that is the right arrangement
A separate API service would need its own copy of the permission model, the field security rules and the audit machinery — and any drift between the two would be a security bug rather than an inconvenience. Serving both from one application means a permission change applies to both at once because there is only one of them.
Scaling it
Scaling the API is scaling the application: more capacity serves both. Where API traffic is heavy enough to want isolating from interactive users, that is a web server and infrastructure arrangement — routing the API path to its own pool of workers — rather than a platform setting.
Treat it as an infrastructure decision and take it with whoever runs your hosting. There is nothing to switch on here.
Two health endpoints, and they answer different questions
- Liveness — returns success as long as the web server is serving requests at all. No database, no session, no application bootstrap.
- Readiness — also checks the primary database is reachable, and fails if it is not.
Point them at the right things
This distinction is the one that catches people out. Use liveness for your load balancer's health check, and readiness for monitoring.
If the load balancer checks the database, a brief database blip takes every application instance out of service simultaneously — turning a short, recoverable problem into a total outage. The liveness check is deliberately cheap and deliberately ignorant of the database for exactly that reason.
The health endpoints are not authenticated
Necessarily — a load balancer cannot hold a credential. They are built to be safe unauthenticated: they do not load the application, do not touch sessions, and never emit connection details in a response.
Logging and retention
Requests are logged by default, with a retention period in days. There is also a switch for whether successful requests are recorded or only failures.
Leave successes on. With them off the log stays small and still answers "why did this integration break" — but it loses "is this key still in use" and every usage statistic. As the setting itself puts it, the honest reading of an empty log should be "nothing happened", not "nothing was written down".
Check the log after any deployment
Integrations fail quietly. They retry, they log at their end, and often nobody tells you for days. A look at the request log for new failure patterns after a release is the cheapest way to find out first.
Worked example
An installation runs behind a load balancer checking the liveness endpoint every ten seconds, with monitoring polling readiness every minute. A database failover takes forty seconds: monitoring alerts, the load balancer keeps every instance in service, and the API returns errors briefly instead of the whole site becoming unreachable.
Recommendations
- Liveness for the load balancer, readiness for monitoring. Never the other way round.
- Keep successful-request logging on.
- Set retention deliberately — the log grows with traffic.
- Review the log after every deployment.