In which application you miss a feature
Arena (API)
Is your feature request related to a problem? Please describe.
No issue, since a workaround exists with additional API calls
Describe the solution you'd like
Return "customId" value in response to API requests to endpoints:
GET /api/{_format}/athlete/get/{id} (Get athlete)
GET /api/{_format}/athlete/{sportEventId} (Get all athletes of an Event)
Since "athenaPrintId" values already exist in both endpoints mentioned above and "customId" belongs to the same "Person" object, I'm assuming that this should not be an issue technically to extend the response for athletes retrieval requests.
Describe alternatives you've considered
As an alternative and workaround, currently, I'm doing additional calls to GET /api/{_format}/person/get/{id}, which works perfectly fine, but significantly increases the number of API interactions, which can be avoided if the "customId" will be present on the same level as "athenaPrintId".
No concern about exposing this attribute on Athlete entities.
It's available for testing in the beta branch and will be part of the next Arena production release
In which application you miss a feature Arena (API)
Is your feature request related to a problem? Please describe. No issue, since a workaround exists with additional API calls
Describe the solution you'd like Return "customId" value in response to API requests to endpoints:
Since "athenaPrintId" values already exist in both endpoints mentioned above and "customId" belongs to the same "Person" object, I'm assuming that this should not be an issue technically to extend the response for athletes retrieval requests.
Describe alternatives you've considered As an alternative and workaround, currently, I'm doing additional calls to GET /api/{_format}/person/get/{id}, which works perfectly fine, but significantly increases the number of API interactions, which can be avoided if the "customId" will be present on the same level as "athenaPrintId".