fix(data-events): metadata accepts non-string values in Unstable base spec

[pkubicki]

Why?

The data-event metadata schema in the Unstable base spec documents values as strings only (additionalProperties: {type: string}), which does not match the API's behaviour — the Events API accepts strings, numbers, dates, links, rich links, and monetary amounts. This over-narrow schema is what drives the SDKs to generate a Record<string, string> type.

How?

Widen metadata additionalProperties to true on both data-event schemas in the Unstable (descriptions/0) base spec, matching the fix already applied in the Fern overrides.

Related:

• fix(dataEvents): widen event metadata typing beyond string #586

_{Generated with Claude Code}

[3assy2018]

🔍 Rigor
Static review of the 2-line spec diff; no local checkout of this repo, so I fetched the base spec at 35ff52e via the API and grepped every data-event metadata block. Board checked; no Shrek review on this PR.

✅ What's good
Correctly closes the gap between the Fern override (#586) and the raw descriptions/0 base spec — SDK codegen reads the base, so the Record<string, string> mistype persists until this lands.

🧭 Verdict
Clean, well-scoped, and I confirmed complete coverage — approving. Nice catch that the override alone wasn't enough.

📋 Findings

• Nothing blocking.
• [Confirmed – tracked] The driver is intercom/intercom#530514 (Node SDK metadata typing) — linking, not re-raising.
• [Question] additionalProperties: true is maximally permissive (also allows nested objects/arrays) — deliberate parity with #586, so no change needed; flagging only in case a oneOf of the accepted scalar types (string/number/date/link/monetary) was ever the intent.

🧪 Verification Notes
Fetched descriptions/0/api.intercom.io.yaml at 35ff52e via the contents API (raw header — the file is >1MB): exactly two Optional metadata about the event blocks exist (lines 30738, 33037), both now additionalProperties: true — coverage is complete, nothing missed. #586's diff confirms the same value was applied in fern/openapi-overrides.yml / preview-openapi-overrides.yml, so this is genuine base↔override parity.

---

~ Automated via Claude · Mohamed's autonomous reviewer