Is your feature request related to a problem? Please describe.
When working with the channel points rewards/redemptions endpoint, the API currently returns only the user_id of the redeemer, without including their username.
This creates unnecessary complexity when building applications that need to display or process user-friendly data.
To obtain the usernames, I currently have to:
- Collect all user_ids from the redemptions endpoint
- Deduplicate them
- Send an additional request to another endpoint to retrieve the corresponding usernames
This results in extra API calls, added latency, and more complex logic on the client/server side.
Describe the solution you'd like
It would be very helpful if the redemptions endpoint included basic user information directly in the response, such as the username.
For example, extending the redeemer object like this:
"redeemer": {
"user_id": 123,
"username": "example_user"
}
This would eliminate the need for additional requests and significantly simplify integration for developers.
Describe alternatives you've considered
The current workaround involves making additional API calls to resolve user IDs into usernames. While functional, this approach:
- Increases API usage
- Adds latency
- Requires extra logic for batching and deduplication
Another alternative would be caching user data locally, but this introduces synchronization issues and stale data risks.
Additional context
No additional context at the moment.
Is your feature request related to a problem? Please describe.
When working with the channel points rewards/redemptions endpoint, the API currently returns only the
user_idof the redeemer, without including their username.This creates unnecessary complexity when building applications that need to display or process user-friendly data.
To obtain the usernames, I currently have to:
This results in extra API calls, added latency, and more complex logic on the client/server side.
Describe the solution you'd like
It would be very helpful if the redemptions endpoint included basic user information directly in the response, such as the username.
For example, extending the
redeemerobject like this:This would eliminate the need for additional requests and significantly simplify integration for developers.
Describe alternatives you've considered
The current workaround involves making additional API calls to resolve user IDs into usernames. While functional, this approach:
Another alternative would be caching user data locally, but this introduces synchronization issues and stale data risks.
Additional context
No additional context at the moment.