Quickstart: verify connectivity with the

2 min read

healthzGrounded liveness probe

no authPublic and unmetered

smoke testFirst check in CI

Call it

curl -s -o /dev/null -w '%%{http_code}\n' \
  https://api.credicorp.co.uk/public/v1/healthz

A 200 confirms DNS, TLS, routing and the API process are all healthy from where you are calling. Any other code points at a network, proxy or firewall issue on the path — not your application code.

Use it as a deploy gate

Wire it into your release pipeline so a deploy fails fast if the API is unreachable from the new environment:

code=$(curl -s -o /dev/null -w '%{http_code}' \
  "$CREDICORP_BASE/healthz")
if [ "$code" != "200" ]; then
  echo "Credicorp API unreachable ($code)" >&2
  exit 1
fi

healthz vs status

healthz is a machine liveness check. For a human-readable component status and incident history, link users to the public status page instead — do not scrape healthz for a dashboard.

Frequently asked questions

Should I poll healthz continuously?

No. Use it for one-off smoke tests and deploy gates. Continuous polling wastes requests; for uptime monitoring use the status page or a single scheduled probe.

Does healthz count against my rate limit?

It is intentionally cheap, but treat it like any request and don't call it in a tight loop.

What does a non-200 mean?

It almost always indicates a problem between you and the API — DNS, a corporate proxy, TLS interception or a firewall — rather than an application bug. Test from a second network to confirm.