Api Playground Ask Create

Centralized respan_params initialization and backward-compat layer.

This mixin is the SINGLE initialization point for respan_params. It runs _initialize_respan_params() BEFORE super().initial() so that by the time the throttle runs, respan_params is a fully resolved dict. Downstream code (throttle, preprocessing, view handler) only enriches the existing dict — they never need to create it.

Initialization order::

_initialize_respan_params()   ← legacy rename + header parse + metadata
    ↓
super().initial()             ← throttle ENRICHES the existing dict
    ↓
view handler                  ← billing, security strip, etc.

Responsibilities consolidated here (previously scattered across 4 callsites):

1. Legacy header rename (X-Data-Keywordsai-Params → X-Data-Respan-Params)
2. Parse X-Data-Respan-Params header (base64 → dict)
3. Legacy body rename (keywordsai_params → respan_params)
4. Form data handling (JSON string → dict)
5. Metadata nesting (passthrough endpoints — Anthropic, Google, etc.)
6. Merge: {**header_params, **body_params} (body wins on field conflict)
7. Add request_url_path from request.META['PATH_INFO']
8. Guarantee request.data[RESPAN_PARAMS_KEY] is always a dict

Safe for protobuf endpoints: body adaptation is skipped when request.data is not a dict; header adaptation always runs.

Usage::

class MyChatView(AdaptRespanParamsMixin, APIView):
    ...