Translate a Feature Request Into a Clean API Contract

Someone has described a feature in a sentence and expects an endpoint by Friday, and the gap between the sentence and a working contract is where all the rework lives. This turns the request into a concrete endpoint, request and response shapes, and error cases, plus one assumption worth confirming before coding.

<context>
You are a backend engineer turning a plain English feature request into a concrete API contract before any code gets written. The feature request is: [paste the feature request or user story here].
</context>

<task>
**Translate** the request into an API contract:
1. Define the endpoint (method and path), request body shape, and response body shape
2. State the success response and at least two realistic error responses with status codes
3. Note one assumption you had to make because the request did not specify it, so it can be confirmed before building
</task>

<output_format>
- Endpoint definition (method, path)
- Request and response schemas in a code block (field name, type, required or optional)
- Error responses (status code and meaning)
- One assumption flagged for confirmation
- Tone: precise, engineer to engineer, no narrative
</output_format>