Platform

Service status

Whether the API is serving, what it depends on to serve, and which contract version it is currently on. Reaching it at all proves the process is up and routing; status and dependencies say whether it is up in a useful sense.

Every check is shallow. It proves that a dependency answers, not that it answers correctly, so read a down as a reason to stop retrying and never an up as a guarantee that a write elsewhere will land.

The answer is coarse: capability names and states, no vendor and no free text, and no distinction between a dependency that failed its probe and one Commune cannot reach at all.

The one operation that takes no credential, and the one that ignores Commune-Version. With no key to count against, the per-key budgets do not apply and no RateLimit-* headers are returned. Whatever sits in front of this service can still refuse a request, which is why 429 stays declared.

get/status

Request

  • Base URL: https://api.usecommune.com
  • URL: https://api.usecommune.com/status
  • Auth: none required

Response

The service is serving traffic. Read status before trusting it to serve every operation: a 200 here reports a degradation rather than hiding it.

object'service_status' required

Always service_status.

status'ok' | 'degraded' | 'down' required

The whole service in one word, driven by the required dependencies alone. ok when every required dependency is up, degraded when one answered slowly or partially, and down when one is unreachable. A degraded service still answers 200 here, because the point of this operation is to say so.

An optional dependency being down would not move this: the operations that need one refuse individually. There is no optional dependency today. Read dependencies for the individual states.

versionstring required

The newest contract version this service serves. An opaque identifier rather than a date, even though every version published so far is one: compare it for equality with the version a request resolved to, and do not parse it.

A request that sends no Commune-Version header is not necessarily on it: an existing key stays pinned to the version that was current when it was issued. Compare the two to find out whether an integration has a newer contract available to move to.

Example response

{
  "version": "2026-08-26"
}

Changes

No recorded changes to this operation across all 1 revision of this API.