Request headers
Your function receives the headers the caller sent. That includes your own: webhook signatures like Stripe-Signature or X-Hub-Signature-256, an Idempotency-Key, a traceparent, whatever your application defines. So you can verify a webhook is authentic before acting on it.
Six headers are removed on the way in, and it is worth knowing why:
| Header | Why it does not reach your function |
|---|---|
Cookie / Set-Cookie | Every slice shares the ondrift.eu apex, so a cookie scoped to it would be sent to every other slice too. Carry sessions in the Authorization header instead. |
X-Forwarded-For / -Host / -Proto, X-Real-IP | Stripped so a caller cannot forge one. Nothing replaces them on the way to your function today, so there is no header your handler can read the caller's address from. |
Four headers are written by the platform on every request, overwriting anything the caller sent:
| Header | Value |
|---|---|
X-Username | The slice's owner. |
X-Slice | The slice name this request was routed to. |
X-User-RPM | The slice's requests-per-minute ceiling. |
X-User-Runtime | The per-invocation runtime budget in seconds. The runner reads it to size the kill timer. |
X-Request-Id is a correlation id, not an identity.
Nothing on the platform generates or checks one: your function receives exactly what the caller sent, or no header at all if they sent none. Any client can choose its own value or omit it entirely. Log it to correlate a request across layers when your caller supplies one; never authorise on it.