Honeycomb API keys

• Provider documentation Honeycomb docs "Authentication": ingest key ids carry hc[x]ik_, "The character shown as [x] varies and is assigned at key creation", and "The key value is the Key ID and Secret concatenated with no separator" (58-byte placeholder body); honeycombio/libhoney-go libhoney.go (02e9dbf, 2026-04-14): classicIngestKeyRegex ^hc[a-z]ic_[a-z0-9]*$ applied when len(key) == 64, with 64-byte hcxik_/hcxic_ fixtures; honeycombio/libhoney-py client.py (11b5941): ^hc[a-z]ic_[a-z0-9]{58}$; re-checked 2026-09-29 · observed 2026-09-29 · hc + one [a-z] + ik_ (environment) or ic_ (classic) + exactly 58 [a-z0-9], 64 in all
• Reference 1
• Reference 2
• Reference 3
• Reference 4
• Reference 5
• Reference 6
• Reference 7
• Reference 8
• Reference 9
• Reference 10
• Reference 11
• Reference 12
• Reference 13

Arrival evidence (#528, product redact-secret#1034; #1014 handoff honeycomb.md, READY for ingest keys). An ingest key sends telemetry into an environment; a leak lets anyone write or spoof events and burn the quota, and ingest keys are routinely pasted into OpenTelemetry collector configs. T1: the prefix and the id-plus-secret concatenation are the docs; the 58-byte body is the docs placeholder, the libhoney-go 64-byte gate and its fixtures (R5); the alphabet is the SDK fixtures (R5) and the classic regex in two provider SDKs (R1). The whole 64 bytes are the span. Excluded: key ids alone (hc?ik_/hc?mk_ + 26, and hc?lk_ and hc?en_ ids; non-secret, shown in the UI and API), 22-character configuration keys and 32-hex classic keys (no distinctive shape; credentials that generic context covers, so authored neither way) and the management key (ISSUANCE-GATED on the alphabet of both segments; authored neither way). Neither pinned peer reads this shape: trufflehog 3.97.4 Honeycomb wants a 32-hex or 22-alphanumeric value near the keyword Honeycomb (classic and configuration keys), and gitleaks 8.30.1 has no rule. Graduated to a registry detector at the 4fb7882 re-pin (redact-secret PR #1039).