# Request

Request or transaction-specific metadata for API services.

Request contexts use these attributes:

| Attribute      | Type    | Source          | Example                              | Private | Notes                                      |
| :------------- | :------ | :-------------- | :----------------------------------- | :------ | :----------------------------------------- |
| _key_          | String  | Generated UUID  | 7D97F0D3-B18C-4305-B110-0317BDB745DC | FALSE   | Random UUID per request                    |
| _anonymous_    | Boolean | Static: `true`  | `true`                               | FALSE   | Always true for request contexts           |
| path           | String  | HTTP Request    | /api/users                           | FALSE   | HTTP request path                          |
| method         | String  | HTTP Request    | POST                                 | FALSE   | HTTP request method                        |
| api-version    | String  | HTTP Header     | v2                                   | FALSE   | API version from X-API-Version header      |
| request-client | String  | HTTP Header     | mobile-ios                           | FALSE   | Name of the requesting client application  |

## Implementation example

Implement a request context like this:

```javascript
const requestContext = {
  kind: "request",
  key: crypto.randomUUID(),
  anonymous: true,
  path: req.path,
  method: req.method,
  "api-version": req.headers['x-api-version'],
  "request-client": req.headers['x-client-name']
};
```

## Use cases

### Coordinate breaking changes across projects

Use this when you manage API versioning with feature flags. For example, serve new response formats only to requests specifying `api-version: v2` or higher. This allows gradual migration.

### Distribute risk by request or transaction

Use this when you roll out new behavior for specific endpoints. For example, enable new validation logic on the `/api/orders` endpoint at 10% while other endpoints remain unchanged.

### Request-level rate limiting or special handling

Use this when you apply different behavior to specific request types. For example, enable aggressive caching only for GET requests. You can also apply stricter validation for POST/PUT/DELETE operations.

### Client-specific behavior

Use this when you serve different responses based on the client. For example, return simplified responses for mobile clients to reduce bandwidth. You can also enable experimental features for internal testing tools.

---

<div class="page-metadata"><table class="page-metadata-table" aria-label="Page metadata"><thead><tr><th scope="col">Last modified</th><th scope="col">Last reviewed</th><th scope="col">Review due</th></tr></thead><tbody><tr><td><time datetime="2026-03-19">2026-03-19</time></td><td></td><td></td></tr><tr><td>Last commit: <a href="https://github.com/launchdarkly-labs/ps-flag-book/commit/d319a7d">d319a7d</a></td><td></td><td></td></tr></tbody></table></div>