Հայերեն
Русский
Українська
ქართული
Қазақша
Español
Français
Deutsch
Italiano
فارسیOverview
The public /api/health endpoint returns an aggregate, non-secret runtime and readiness status for the VPOS.am platform.
Live aggregate platform health
This view reads a non-secret same-origin health endpoint and exposes only a small public readiness summary.
What public health reports
GET /api/health returns ok, ready, service, version, mode, generatedAt and an aggregate readiness object. The top-level ready flag is suitable for a general uptime/readiness check, while blockers and warnings help diagnose the platform state.
Diagnostic blocker text is not a stable API contract. Automated monitoring should depend on documented fields and retain generatedAt so that a fresh response can be distinguished from stale data.
Boundary of the aggregate status
ready=true means that the shared runtime passed its current platform-level checks. It does not prove that a specific merchant has an active contract, credentials, installation binding, callback, fiscal profile or approved production provider route.
Merchant-specific readiness is confirmed separately through the console/onboarding flow and a test payment. External bank or provider health also cannot be inferred from the aggregate VPOS health response alone.
How to use the signal operationally
A monitor can poll /api/health and alert operations when ready=false or a fresh response is unavailable. Investigate a single payment, webhook delivery or provider callback by payment id, merchantOrderId and the logs for that installation.
Public health is neither an SLA promise nor an incident-history feed. Confirmed impact on a specific client and recovery actions are communicated through the agreed support channels.
FAQ
What does ready mean in the /api/health response?
It is the aggregate result of the current platform-level readiness checks at generatedAt. It is suitable for shared runtime monitoring, but does not confirm a specific merchant or provider route.
Does ready=true approve a merchant for production?
No. A specific installation separately verifies the contract and credentials, token binding, provider route, callbacks/webhooks, test payment and production approval.