Currently, custom_reward.id is:

Publicly visible via unauthenticated GraphQL responses in the Twitch frontend (to anyone with DevTools).

Blocked in the Helix API unless the request is authenticated as the broadcaster and includes elevated scopes.

This architectural inconsistency causes confusion and unnecessary friction for developers.

A well-structured access model should behave consistently:

If custom_reward.id is public (as its frontend exposure implies), it should be accessible via Helix in a read-only context — no scopes required.

If it’s private, then it should not appear in frontend GraphQL queries without authentication.

This is not a feature request.
This is about fixing a fundamental inconsistency in the platform’s data access model.

Twitch developers rely on predictable and consistent APIs when building integrations like overlays, bots, or analytics. Forcing them into undocumented workarounds (e.g., scraping) degrades both developer trust and platform integrity.

Please consider:
Allowing custom_reward.id to be accessed via Helix in read-only mode, without requiring authentication, or

Restricting its frontend exposure, if it is meant to be protected.

If Twitch treats 1st-party and 3rd-party differently, that distinction should still preserve internal consistency. A data field should not be both “public” and “private” depending on which API surface you're looking at.

Let’s fix this — not because it's convenient, but because it’s the correct architectural behavior.