Platform operations
Health checks and cache refresh. Called by your monitoring, not by a cardholder journey.
healthCheck
Performs a health check on the CoreBankingIntegrationIndoor service, returning the current server date and a result status.
Headers
evrst-ptrnidCorrelation id for this request. Echo it in your own logs to trace the call through the platform.
healthCheck › Responses
Success.
The answer is built in memory and is unconditional. The operation opens no database connection and calls no downstream service, so a 200 says that the service process is running and able to answer, not that its database or the services behind it are reachable. result is a fixed constant, the same on every call, and date is the server's local clock at the moment of the call.
dateA date and time as a string, in RFC 3339 form: 2026-10-16T14:30:00Z, or with an offset, 2026-10-16T17:30:00+03:00.
resultThe outcome, as the downstream system words it.
refreshCache
Refreshes and loads all cached data including card products, parameters, BINs, card statuses, campaigns, statement operation codes, MCC groups, transaction statuses, applicable products, and domestic BINs. Provides helper methods to get cached values and validate PIN patterns.
Headers
evrst-ptrnidCorrelation id for this request. Echo it in your own logs to trace the call through the platform.
refreshCache › Responses
Success.
The response carries no body; a 200 is the only signal that the reload finished. The call rebuilds the in-process cache from the parameter service, slot by slot in a fixed order, and it is this cache that getMccGroupAll, getTrnStatusAll and getBinDomesticByBin read. The card product slot is loaded first and is the only one whose contents are checked: if the parameter service returns no card products the reload throws and the remaining slots are left as they were. The operations that read the parameter database directly, such as getTrnCodeDefByValidFlag and the other ByValidFlag lists, are unaffected by this call.