Framework quickstarts
Neens is a neutral inlet: it ingests standard OpenTelemetry — there is no Neens SDK to adopt and nothing to fork. To connect a framework you already use, you install its OpenTelemetry instrumentation (most often the community OpenInference instrumentors, or the framework’s own built-in OTel support) and point the exporter at the Neens OTLP endpoint. That’s it — the same wiring works for any OTel-instrumented app.
Each recipe below is copy-paste: install, point the exporter at https://<your-neens-host>/v1/traces
with your nk_live_… agent key, run your agent, and watch traces land under Traces.
The common contract
Every recipe wires the same three things — only the instrumentation package changes:
| Endpoint | POST https://<your-neens-host>/v1/traces (OTLP/HTTP). Standard exporters append /v1/traces to OTEL_EXPORTER_OTLP_ENDPOINT automatically. |
| Auth | Authorization: Bearer nk_live_… — an agent API key from Settings → API keys. |
| Attributes | Neens reads standard OTel-GenAI and OpenInference attributes (model, tokens, prompt/response messages, tool calls, conversation id) — per field, first match wins. |
Not using one of these frameworks? Any OpenTelemetry-instrumented app exports to Neens the same way — see Send traces for the endpoints, size limits, response codes, and the full semantic-convention attribute reference. Prefer to send raw JSON instead of OTLP? That’s supported too.
Correlating pre-prod eval traces
Running these traces through a pre-prod evaluation gate in CI? The
neens-eval runner (Python and TypeScript) injects the neens.eval_run_id /
neens.dataset_item_id / neens.version_label correlation attributes into OTEL_RESOURCE_ATTRIBUTES
for you, so the traces your instrumented agent emits above are automatically tied to the right run.
Those three attribute names are a stable wire contract — if you tag traces yourself instead of
using the runner, spell them exactly as listed above.