Headers

View as Markdown

Request-Id

Krenalis includes a unique request identifier in the Request-Id header of every API response.

HTTP/1.1 200 OK
Content-Type: application/json
Request-Id: E45q3XNtPNyvzStrPTEoSvtMgyCquuJAZHHSpdgcYCeA

{
  "id": "user_123",
  "name": "Jane Doe"
}

Use the request ID to trace a specific API request when debugging an issue. In a self-hosted deployment, you can use it to find related entries in your logs. When using Krenalis Cloud, include the request ID when contacting support about an API issue.

Treat request IDs as opaque values. Don't parse or modify them. A request ID isn't an authentication token and doesn't grant access to any resource.

Sync-Token

Krenalis returns a Sync-Token header with every successful 200 OK response.

You can include this token in any subsequent API request:

Sync-Token: <token>

When a request includes a Sync-Token, Krenalis guarantees that the request runs against application state that is the same as, or newer than, the state observed or produced by the request that returned the token.

Treat the token as an opaque value. Don't parse, modify, or compare it.

Multi-node deployments

Sync-Token is most useful when Krenalis runs on multiple nodes.

State changes may take time to propagate between nodes. Because consecutive requests can be handled by different nodes, a later request may otherwise observe an older state.

For example:

  1. Request A runs on one node and returns a Sync-Token.
  2. Request B is sent after Request A completes.
  3. Request B runs on another node that hasn't received the latest state yet.

Without a Sync-Token, Request B may observe state older than the state observed or produced by Request A.

To prevent this, pass the token returned by Request A with Request B:

Sync-Token: <token-returned-by-request-a>

Krenalis processes Request B only against application state that is at least as recent as the state represented by the token.

Single-node deployments

In a single-node deployment, consecutive requests always observe the same or a newer application state, so you don't need to include a Sync-Token. If you include one, it has no effect.

Example

Response from the first request:

HTTP/1.1 200 OK
Sync-Token: U3luY1Rva2VuOjAxSllXWk5GN0hXMk5LQzJNUkY4VjY4RjIAv5

Subsequent request:

GET /v1/pipelines/7XcP4mZ9aQ2r
Sync-Token: U3luY1Rva2VuOjAxSllXWk5GN0hXMk5LQzJNUkY4VjY4RjIAv5

The second request is guaranteed to run against application state that is the same as, or newer than, the state observed or produced by the first request.