Batch & status

Ping

A minimal liveness probe: prove a freshly minted kor_live_ key authenticates, and read back its tier, its storage and processing regions, and its scopes.

GET /v1/ping

The first call to make after minting a key. It confirms the bearer token resolves to a live key, surfaces the tier and granted scopes you'll use to reason about access, and says at the wire where your data is stored (region, always in the EU) and where the model that writes your facts runs (processing_region, the region of the key's project).

Authentication

HTTP header, required: Authorization: Bearer kor_live_....

Query parameters

None. /v1/ping takes no query parameters, no path parameters, and no request body, just the Authorization header.

Example request

curl https://api.korely.ai/v1/ping \
  -H "Authorization: Bearer kor_live_..."

from korely_memory import Korely

korely = Korely()  # reads KORELY_API_KEY
p = korely.ping()
print(p.ok, p.tier, p.region, p.scopes)
# True hobby eu-hel1 ['memories:read', 'memories:write']

import { Korely } from "korely-memory";

const korely = new Korely(); // reads KORELY_API_KEY
console.log(await korely.ping());
// { ok: true, tier: "hobby", region: "eu-hel1", processing_region: "global", scopes: [...] }

korely ping
# ok  tier hobby  region eu-hel1  scopes memories:read, memories:write

Response

200 OK. Confirmation that the key authenticated, plus its tier, its storage and processing regions, and its granted scopes.

{
  "ok": true,
  "tier": "hobby",
  "region": "eu-hel1",
  "processing_region": "global",
  "scopes": ["memories:read", "memories:write"]
}

Field	Type	Description
`ok`	boolean	Always `true` on success, confirms the `kor_live_` key authenticated.
`tier`	string	The API key's billing tier, e.g. `hobby`.
`region`	string	Where the data of the key is stored: the server's configured EU region (`eu-hel1`, Helsinki). The same for every key and every project.
`processing_region`	string	Where the language model that writes the key's project's facts runs: `global` (Google Gemini, the default) or `eu` (Scaleway, Paris). Chosen per project; see Regions.
`scopes`	array[string]	The scopes granted to the key; an empty list if the key has no scopes.

Errors

Status	Code	Cause
`401`	`invalid_key`	The `Authorization` header is missing or empty, or the bearer token does not resolve to a live key. The body is the standard error envelope, e.g. `{"code": "invalid_key", "message": "Invalid or missing API key: no live key matches it (a revoked key stops at once); your keys are at https://agent.korely.ai/keys"}`, with a `WWW-Authenticate: Bearer` header. Branch on `code`: the message differs for some keys.
`500`	`internal_error`	The request failed on our side.

Notes

Auth-only. Ping depends only on a valid key, there is no scope requirement and no rate limiting, so it never returns 403 or 429.
Source of each field. tier and scopes come from the key itself; region is read from the server's configuration, not the key; processing_region from the project the key belongs to. scopes defaults to an empty list [] when the key has none.
In the SDKs. ping() in Python and Node, korely ping (or korely auth) in the CLI. Node returns the JSON as the server sends it. The Python PingResponse and the CLI show ok, tier, region and scopes; read processing_region over REST, or from Node.
Side effect. Resolving the key stamps its last_used_at, so a ping also serves as a heartbeat for the key.
Use it in CI. A green ping is the fastest signal that your key, region binding, and EU endpoint are all wired correctly before you touch the memory endpoints under /v1/memories/{memory_id}.

Add a memory, the first real write once ping is green.
Get context, read back the assembled recall block.
SDK, the typed client, with ping().