Data Subject Rights query (GDPR Art 15)

Zero-auth GDPR Article 15 transparency endpoint. Accepts EXACTLY ONE of name (case-insensitive substring search across cached signaturrett / prokura / board_members / innehaver role-holder names) or org_number (9-digit Norwegian organisation number). Returns the cached Tier 1 data Apier holds about the requester, with data_source / legal_basis / retention_period annotations on every field — the response is self-describing without the caller needing to hit /privacy or /trust separately.

No authentication required. This is a zero-auth surface — Apier does NOT verify that the queried name or org_number actually belongs to the requester. The endpoint reports what's cached for the submitted query string; Article 15 verification is the requester's responsibility (per Datatilsynet's self-service interpretation for public-register data). Privacy safeguards: (a) 10 requests / 60s sliding window per IP — prevents bulk-enumeration; (b) SHA-256-hashed audit-log row per request — the queried name is never stored in plaintext; (c) data minimization — the response is scoped to what Apier actually caches and never enriches with personal data Apier deliberately doesn't store (no birth dates, no addresses, no national identity numbers). The exact response shape varies by query mode: name queries return role_attestations (one row per (org × role) match — matched_name plus the coarse role enum signaturrett / prokura / board_member / innehaver, no other fields about the matched person); org_number queries return company_records with every public Brønnøysund column the route exposes (name, entity_type, NACE codes, status, municipality, signaturrett, prokura, board_members, innehaver), each field carrying its own data_source / legal_basis / retention_period triad. Array-backed columns (nace_codes and the four role-holder lists) are FLATTENED to comma-separated strings on this surface — DsrField.value is string | null for every key, never an object array, so callers should not expect structured role-holder objects here. The flattening is the documented data-minimisation contract: only the role-holder name appears, never the role label or signing rule.

Idempotency-Key not supported on this endpoint. The repo convention is that POST endpoints under /api/v1/* support Idempotency-Key. DSR is the documented exemption: it's a GDPR Article 15 transparency surface, not a consumer-data mutation surface. Every request is a separate disclosure event that MUST land its own audit row for legal-defensibility purposes — deduplicating replays would let a data subject's repeat queries silently merge into one audit entry, eroding the forensic record Datatilsynet may inspect. The append-only audit row IS the side effect, and intentionally-correct duplicate audit rows on replay accurately reflect that the data subject queried twice. Privacy controls (rate limit, hashed name, hashed IP) are independently enforced and protect against bulk-enumeration without needing dedup.

Correction path: Brønnøysund is the upstream source of truth. Corrections must be requested at Brønnøysund — they propagate to Apier at the next sync cycle (within 24 hours). Deletion of cached rows is handled by emailing the privacy contact (see response.how_to_request_correction).