What to put in a curl command when reporting a broken API request

A curl command for a broken API request should include the method, URL, essential headers, body, and expected response while redacting private values.

The goal is not to recreate the entire app. The goal is to give another developer a request they can run or compare. A useful command shows whether the bug survives outside the browser, mobile client, retry layer, or SDK. It also reveals accidental differences such as content type, missing authorization prefix, wrong environment host, or a body field encoded differently than expected.

Start with method and endpoint. A missing `-X PATCH` or a copied production path pointing at staging can waste time. Then add only the headers that matter: authorization shape, content type, accept header, idempotency key, tenant or region header, and any version header. Remove browser-only noise unless the bug depends on it. If a cookie is required, redact the value and say whether it was present.

For the body, keep the smallest failing payload. Delete optional fields until removing one changes the result. Keep field names and value types realistic. A validation bug can disappear if a redacted example changes a string into a number, an empty array into null, or a timezone into a plain date.

Include the observed result next to the command: status code, short response body, request id if safe, and timestamp. Also include the expected result in one sentence. Without the expected result, the receiver may reproduce the behavior but still not know why it is wrong.

The practical rule: a good curl report is safe to share, small enough to scan, and accurate enough that the next person does not need to guess which client behavior matters.

What to put in a curl command when reporting a broken API request

// COMMENTS

ON THIS PAGE