Review an API before launch with Ruthless

Build a request map from real code

Use a concrete example: POST /api/projects creates a project for the signed-in account. Gather the route, middleware, session helper, validation schema, persistence call and response shape. Include the expected status codes and an example response with fake values. Ask Ruthless to trace which function owns each decision and cite the supplied file or symbol.

State what is intentionally public and what needs identity. Authentication establishes who is making the request; authorisation establishes whether that identity may perform this action on this resource. A route can have valid authentication and still let one account modify another account’s project. Check both boundaries explicitly.

Use fake fixtures that expose account boundaries

Create two disposable accounts and projects owned by each in a development or test environment. Use fictional names and addresses. A valid request from account A should create its project and return only the fields allowed by the contract. A request without identity should fail as designed and leave no new row.

Next send account B’s project identifier while authenticated as A. Check the response and the database effect, including background jobs. The important outcome is that B’s project remains unchanged. Do not paste live tokens or customer records into a review conversation. Supply redacted code and fake fixture descriptions instead.

Test inputs, outputs and billing side effects

Try missing required fields, malformed JSON, unsupported field values and unexpected extra properties. Set expectations from your actual contract rather than accepting any error as success. Inspect whether the response reveals internal stack traces or private fields. Test a normal request after an invalid one to catch state accidentally carried between requests.

If an endpoint can charge, use the billing provider’s documented test mode and verify its test identity before triggering it. Check the test receipt and your application’s stored state. Simulate a repeated callback or request according to your implementation and verify that the intended purchase or credit appears once. Do not assume a mocked HTTP success proves real billing integration.

Ask Ruthless to identify where duplicate detection happens and what survives a process restart. Record whether the route writes before or after an external call. A timeout can leave the external action completed while your application remains uncertain; your review should identify the existing reconciliation path and the original operation identity rather than suggest a blind second purchase.

Turn the review into a small evidence bundle

Use a route-by-route record of expected response, actual response and actual side effects. For the project endpoint, include successful creation, missing identity, cross-account access and malformed input. Add the relevant failure case for any external dependency. Store secrets outside the bundle and describe fixtures without real personal data.

Ask Ruthless to challenge discrepancies and propose focused repairs, then rerun the affected cases. This can improve review coverage, but neither a model answer nor a clean checklist establishes compliance or a security guarantee. A launch decision still depends on the real environment, the changes made and your release authority.

Keep claims precise: “cross-account fixture could not modify the other project” is evidence; “the API is secure” overstates it. Note unavailable checks and who will complete them. Use GetRuthless chat for supplied context or its documented Chat Completions API for a repeatable review harness; neither automatically reaches your private development server. [1]

Review this API before launch. Trace each supplied route through identity, ownership checks, input parsing, persistence, external calls and response filtering. For every concern, cite the supplied symbol and give a fake fixture, expected response and expected side effect. Identify facts you cannot verify. Do not claim execution. Context: [contract and redacted implementation].