Context:

Currently, the Ticket retrieval data structure only returns internal database IDs for several key ticket attributes instead of their user-facing frontend names.

This creates friction because developers have to perform extra manual testing to discover what each internal ID maps to, and it requires building and maintaining a custom mapping table just to display human-readable ticket details or map backend values for create/update operations.

It would be highly beneficial if the returned Ticket payload included the corresponding frontend/human-readable values alongside the IDs.

Currently, the only alternative is manually mapping these values or making separate configuration calls to fetch the ID-to-name metadata, which adds unnecessary overhead and latency to our integration.

Thank you