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:
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.