# Headers



## `Request-Id`

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

```http
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:

```http
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:

```http
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
HTTP/1.1 200 OK
Sync-Token: U3luY1Rva2VuOjAxSllXWk5GN0hXMk5LQzJNUkY4VjY4RjIAv5
```

Subsequent request:

```http
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.