Context
wisdom-agents needs to make network calls on behalf of specific users (its entity owners) without each user handing over an API key. The wisdom side gains a service-key + X-On-Behalf-Of delegation mode (see companion ticket). This ticket adds matching support to the SDK.
Scope
Minimal additive change: a new optional constructor param that, when set, attaches an X-On-Behalf-Of header to every request.
class IntunoClient:
def __init__(
self,
api_key: str,
base_url: str = DEFAULT_BASE_URL,
timeout: float = 30.0,
*,
act_as_user_id: Optional[Union[UUID, str]] = None,
):
...
class AsyncIntunoClient:
def __init__(
self,
api_key: str,
base_url: str = DEFAULT_BASE_URL,
timeout: float = 30.0,
*,
act_as_user_id: Optional[Union[UUID, str]] = None,
):
...
When act_as_user_id is set:
- Every outbound request carries
X-On-Behalf-Of: <uuid> alongside the normal auth header
- The
api_key passed in is expected to be the service key (the backend enforces this; SDK doesn't judge)
X-Service-Key header used instead of / alongside X-API-Key — match whatever the backend ticket lands on (recommend X-Service-Key for clarity, sent only when act_as_user_id is present)
Header layout (final)
| Scenario |
Headers |
| Normal SDK user |
X-API-Key: wsk_... (or Authorization: Bearer eyJ...) |
| Service delegation |
X-Service-Key: <service-secret> + X-On-Behalf-Of: <user_uuid> |
Keep them mutually exclusive in the SDK — if act_as_user_id is set, drop X-API-Key and send X-Service-Key instead. Backend's new auth dep accepts either pattern.
Version bump
Additive change; constructor-compatible. 0.4.0 → 0.5.0 (MINOR).
Acceptance criteria
Out of scope
- New methods or endpoints — purely a header-plumbing change
- Per-call override of
act_as_user_id — the constructor is per-entity-client anyway
Relates to
- wisdom
[personal-service-auth] — companion backend work
- wisdom-agents
[personal-agents-delegation] — main consumer of this change
Context
wisdom-agents needs to make network calls on behalf of specific users (its entity owners) without each user handing over an API key. The wisdom side gains a service-key +
X-On-Behalf-Ofdelegation mode (see companion ticket). This ticket adds matching support to the SDK.Scope
Minimal additive change: a new optional constructor param that, when set, attaches an
X-On-Behalf-Ofheader to every request.When
act_as_user_idis set:X-On-Behalf-Of: <uuid>alongside the normal auth headerapi_keypassed in is expected to be the service key (the backend enforces this; SDK doesn't judge)X-Service-Keyheader used instead of / alongsideX-API-Key— match whatever the backend ticket lands on (recommendX-Service-Keyfor clarity, sent only whenact_as_user_idis present)Header layout (final)
X-API-Key: wsk_...(orAuthorization: Bearer eyJ...)X-Service-Key: <service-secret>+X-On-Behalf-Of: <user_uuid>Keep them mutually exclusive in the SDK — if
act_as_user_idis set, dropX-API-Keyand sendX-Service-Keyinstead. Backend's new auth dep accepts either pattern.Version bump
Additive change; constructor-compatible. 0.4.0 → 0.5.0 (MINOR).
Acceptance criteria
act_as_user_idkwarg on both client constructorsact_as_user_id→ noX-On-Behalf-Ofheader,X-API-Keysentact_as_user_id=<uuid>→ bothX-Service-KeyandX-On-Behalf-Ofsent, noX-API-KeyOut of scope
act_as_user_id— the constructor is per-entity-client anywayRelates to
[personal-service-auth]— companion backend work[personal-agents-delegation]— main consumer of this change