Headers
x-tagshape-auth
The JWT. Used as both a header and a cookie, under the same name.
| As a | Sent by |
|---|---|
| Header | Service-to-service calls, and any machine caller |
| Cookie | A browser calling its own site — this is how the management UI's token refresh arrives |
Anything reading a request's identity looks in both, in that order. Looking in only one takes a signed-in caller for an anonymous one.
GET /variablevalues?set=1 HTTP/1.1
x-tagshape-auth: eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9...
It is also a response header: POST /apikeyjwt on the identity API returns the minted token in it.
x-tagshape-api
An API key, presented to be exchanged for a JWT.
POST /apikeyjwt HTTP/1.1
x-tagshape-api: <api key>
Read from the header only, never a cookie. A key belongs to a machine caller with no session and no cookie jar, and honouring one from a cookie would let any site a signed-in user happens to visit spend their key for them.
Only POST /apikeyjwt reads it. Everything else wants the JWT.
x-tagshape-org
Names the organization a request is signing in to, for the auth UI, where nothing in front of the deployment sets it per request. The Aspire host sets it as an environment variable for local development.
Standard headers
| Header | |
|---|---|
Content-Type: application/json | On every request with a body |
Accept | Honoured normally. POST /generatejwt answers text/plain — the token is not JSON |
No Authorization header
TagShape deliberately does not use Authorization: Bearer. The token travels in x-tagshape-auth so that the
same name works as a header and as a cookie, which is what lets a browser session and a service call be read by
one piece of code.
Quick reference
| Header | Direction | Carries |
|---|---|---|
x-tagshape-auth | Request (header or cookie) | The JWT |
x-tagshape-auth | Response | A newly minted JWT, from POST /apikeyjwt |
x-tagshape-api | Request (header only) | An API key, to be exchanged |
x-tagshape-org | Request | Which organization is being signed in to |