What belongs in a useful API 500 reproduction packet?

Asks what details make an API 500 report actionable without dumping whole logs.

When an API endpoint returns 500 but the UI only shows a generic error, I find the useful report is usually small: action, request path, timestamp, request id, expected result, actual result, and one log excerpt. Long chat threads and full logs often make the first comparison slower. What do you always include in a reproduction packet so another developer can rerun the case without asking three follow-up questions?