VeraFi API Status and Incidents

The VeraFi Backend API is built to deliver stable, reliable, and consistent performance across all of its verification, authentication, configuration, and subscription workflows. The platform incorporates built-in mechanisms that allow integrators to verify system availability, monitor service responsiveness, and detect operational issues. At the core of these mechanisms are the root endpoint and the dedicated health-check endpoint, both of which enable quick and automated checks to ensure that the API is running before downstream processes are triggered. These endpoints function as lightweight validation tools, helping developers confirm that the system is accepting requests and responding correctly.

In situations where operations encounter errors, the VeraFi API provides clear and structured responses using standard HTTP status codes and JSON-based error formats. These responses help distinguish between input validation errors, authentication or authorization problems, exceeded rate limits, and internal server errors. For instance, authentication endpoints enforce strict rate limits; therefore, repeated login attempts within a short interval may trigger rate-limit errors from the same IP address. Similarly, document and verification endpoints may return validation errors if the request payload is incomplete, improperly structured, or missing mandatory fields. When internal issues arise, the API returns the appropriate server-side status codes, signaling temporary service degradation or unexpected processing failures.

VeraFi also includes usage-related and verification-count endpoints that allow clients to observe their resource consumption. These endpoints serve dual purposes: they help tenants manage their subscription usage and indirectly indicate system stability. Consistent and predictable usage statistics typically reflect normal system behavior, while unexpected patterns may indicate workflow disruptions or systemic issues requiring further attention. Additionally, operations related to subscription tiers, tenant details, and configuration management offer structured outputs that make it possible to detect anomalies in operational behavior.

While the documentation does not specify a formal incident reporting or notification pipeline, integrators are encouraged to rely on error messages, rate-limit indicators, and health-check results when determining system status. These components collectively provide enough insight for developers to distinguish between problems caused by incorrect request usage and those arising from potential backend service interruptions. By observing these indicators, clients can quickly assess whether an issue requires correction at the integration layer or whether it reflects a system-level concern that may require support assistance.