Bring your own data (CSV/JSON import)

Already have historical events — exposures, model calls, conversions — from before you adopted LLMJury? Bulk-import them instead of replaying traffic.

The import endpoint

curl -X POST "https://api.llmjury.com/v1/events/import?format=csv" \
  -H "X-API-Key: sk_your_secret_key" \
  --data-binary @events.csv

• Secret key only — import is a server-side operation; publishable keys are rejected.
• format is csv (default) or json — set as a query param, not a content-type header. CSV: the first non-blank line is the header row; column names should match the event schema fields (event_id, type, experiment_id, user_id, variant, timestamp, plus metric fields like prompt, response, model, business_metric, value). JSON: the body is a single top-level JSON array of row objects with the same fields — not newline-delimited. The dashboard's CSV importer wraps the same endpoint.
• If your file uses different column/key names, pass mapping as a JSON object mapping event-field name to your source name, e.g. ?mapping={"user_id":"uid"}. Omit it for an identity mapping.
• The response is synchronous, not a queued job: { "events": [...], "errors": [{ "row": 12, "message": "..." }], "imported": 41 }. Rows are validated individually — bad rows come back as per-row errors keyed by the row number in the file you submitted; good rows are ingested immediately.
• Dedup is by client-generated event_id, so re-running an import is safe (idempotent).

Notes

Imported events flow through the same pipeline as live events — judged, rolled up, SRM-checked, FDR-corrected. Timestamps are preserved, so the analysis window reflects when events actually happened; events older than your plan's retention are not analyzable.