You are handed a REST endpoint with no documentation. What do you test?

Start with the contract: status codes, response schema, content types, and required versus optional fields. Then validate every input (missing, wrong type, out of range, oversized), test authentication and authorization including access to another user's resource, check error response consistency, idempotency on duplicate submissions, pagination and sorting, rate limiting, and behavior when a dependency fails or times out.

First I map the contract, because with no docs I need to know the shape before I can judge it. Happy path call, then look at the status code, the headers, the response body, and whether fields are consistently named and typed. Then I attack the inputs one at a time: omit each required field, send a string where a number belongs, send a negative, send a value past whatever length looks reasonable, send extra fields it did not ask for and see whether it rejects them or quietly ignores them. Then the part I care most about, which is authorization as distinct from authentication. Being logged in is not permission. So I take a valid token from one user and request another user's resource by ID, because that class of bug is common and genuinely severe. After that: does a repeated POST create two records, does pagination behave at page zero and past the end, are error bodies consistent in shape, is there rate limiting, and what happens when a downstream service is slow. I will point a proxy at it and tamper with responses to see whether it degrades or throws a 500.