Windward Software Customer Care

Source of truth: ServerMethodsHealthCheck.pas, CM_Health.pas, ServerMethodsBase.pas (WebAPI_Connect_Base, InternalConnect, CheckPervasive, ValidateDBConnectionInternal, DoValidateDBConnection), ServerMethodsWebAPI.pas (VerifyFundamentalConnections).

There are four different "is it working?" endpoints and they answer four different questions. Using the wrong one is the most common monitoring mistake with this service.

The four probes, and what each actually proves

Use them in that order when diagnosing a problem: each one that passes narrows the fault to the next layer.

GET /HealthCheck/Health_Check

GET /Windward/WebAPI/HealthCheck/Health_Check
Authorization: Basic base64("HealthCheck:anything")

{ "API Health Check": "I am here!", "Version": "1.2.3.4" }

The HealthCheck credential bypass

If the username is exactly HealthCheck (case-sensitive), the authentication handler grants the HealthCheck role and returns immediately — before the database check, the user lookup, the password test and the department check. The password is never examined.

That makes this the right probe for a load balancer or uptime monitor: it is cheap, it needs no real credential, and it never queues behind the service's global lock waiting on a database call.

It also makes it useless as an integration health check:

Important: Health_Check will keep returning "I am here!" while the Pervasive/Zen engine is down, the dataset is unreachable, the licence has expired, or the service is pointed at the wrong data directory. It proves only that the process is alive.

The HealthCheck credential cannot be used for anything else — the HealthCheck role authorises only this one class.

Recommended monitor configuration

Poll liveness frequently; poll readiness sparingly. Connect opens a System Five session and takes the global lock, so a tight polling interval will compete with real traffic.

GET /{Class}/{X}_Handshake

Every class except HealthCheck exposes a handshake:

{ "System Five Invoice API": "Handshake", "Version": "1.2.3.4" }

A handshake requires valid credentials, so a 200 with this body confirms that your username, password, user status and department access are all good. It does not open a dataset session.

Version is read from the S5WebAPISvc.exe file version resource. Record it when reporting a problem — behaviour differs across builds (the Update Inventory Supplier setting and the Invoices2 endpoint, for example, were added in specific builds).

GET /TServerMethodsWebAPI/Connect

The real readiness probe. It runs InternalConnect, which establishes a System Five session against the configured data directory.

Success returns the legacy envelope with Response: "Success". Failure returns Response: "Failed" with a reason.

VerifyFundamentalConnections — the gate that runs before every operation on the TServerMethodsWebAPI class — reports the same two failure modes, so these messages will also appear on ordinary calls:

Pervasive / Zen check messages

Produced by TServerMethodsBase.CheckPervasive:

The user-count message is the one to watch in production: it appears when the site has exhausted its Zen user licences, and the API is competing for those licences with ordinary System Five workstations.

POST /Vendors/ValidateDB

Answers a question none of the others can: is this service connected to the dataset I think it is?

{ "Terminal": 1, "Desc": "prod-2026-09-01-a7f3" }

The service reads the System Five setup value ('SQL', 'TEMP', Terminal) from its connected dataset and compares it, as a string, to Desc.

How to use it

1. From inside System Five — or from any tool with a verified connection to the dataset you intend — write a unique marker into that setup slot for a chosen terminal number. Something dated and environment-specific works well: prod-2026-09-01-a7f3.
2. Store the same marker in your integration's configuration.
3. Call ValidateDB at startup and after any deployment.

Responses

{ "Success": "Y", "Result": "Connection Successful" }
{ "Success": "N", "Result": "Failed; The Web API service is connected to a different database!" }
{ "Success": "N", "Result": "Required Validation Parameters missing" }

Success is the string "Y" or "N", not a boolean, and there is no APIResponse wrapper.

Required Validation Parameters missing means Terminal or Desc was absent; it is also returned when Desc is present but empty, because the comparison is skipped for an empty marker.

Important: This is the guard against the most damaging deployment mistake with this service: an API instance left pointing at a test or restored copy of the data directory, quietly accepting writes that never reach production. Run it after every deployment and every data-directory change.

The operation is declared on the Vendors class for historical reasons and has nothing to do with vendors.

Interpreting a failure

Every request is logged to the Windows event log (and to Log Analytics where configured), with verbosity controlled by the [System Five Web API Service] INI section. When a message in the body is not enough, the event log entry for the same call carries the parameters and the exception detail.