fix(fleetbase-api): audit and fix failing collection requests (85 -> 124 passing)

[roncodes]

Audit of every failing request in the Fleetbase API collection, run against a live stack with a real API key. Two systemic defects accounted for most of it.

Measured: 124 of 195 requests return 2xx, against 85 of 180 at baseline. 39 more requests green, 24 fewer failures. Every number here comes from an actual run, not inspection.

1. Deletes destroyed the fixtures the rest of the run depends on

Delete a Driver removes {{driver_id}} at order 5000 — but seven later requests in the same folder and four in later folders still reference it. This is the cause of the POST /v1/issues → 404 that started this audit: Issues/Create an Issue sends {"driver": "{{driver_id}}"}, and by then the driver is gone, so IssueController::create returns its own 'Driver reporting issue not found.'

The request was never wrong. The same payload against a live driver returns 201 Created — I verified that directly before changing anything.

Fifteen create/delete pairs had this shape. Each delete now targets a throwaway record created immediately before it, so DELETE coverage is unchanged and the canonical id survives the whole run.

2. Eight create requests never captured the id they created

Create a Device, Create Equipment, Create a Fuel Report, Create a Fuel Transaction, Create an Issue, Create a Part, Create a Sensor and Create a Work Order had no afterResponse script at all. So {{device_id}}, {{issue_id}} and the rest were never set, and every Retrieve/Update/Delete built a URL containing a literal {{...}} — which the encoder escaped, producing the %7B%7Btracking_number_id%7D%7D URLs seen in CI.

3. One hardcoded id

Update an Order carried a literal quote_hZ3C21KVkx — an id from someone's local environment that cannot exist anywhere else. Now {{service_quote_id}}.

Deliberately not done

Disposable creates were not added for Work Orders, Fuel Transactions, Payloads, Entities and Tracking Statuses. Their own create requests still fail, so a disposable would only add another failing request. I tried it, measured it going backwards (70 → 76 failures), and reverted.

What still fails, and why

71 remain. They are not collection-shaped problems in the main:

cluster	n	cause
Customers	15	needs an emailed/SMS verification code. requestCreationCode only sends it and never returns it, with no dev bypass — unobtainable from a collection. Also customer_identity, customer_password, verification_code are declared nowhere.
Fuel Transactions	8	Create a Fuel Transaction returns 500
Parts	4	Create a Part returns 500
Entities / Payloads	10	creates return 422 — request bodies need correcting against current validation
Work Orders	5	Create a Work Order returns 404 resolving its target/assignee
Drivers (auth)	6	driver login needs driver_identity / driver_password / a verification code
Onboard	1	endpoint throws a 500
Orchestrator	1	503 — vroom service
Organizations	1	List Organizations wants a platform token, not an org API key

The 500s (Fuel Transactions, Parts, Onboard) look like genuine API bugs and are worth their own issue — they cannot be fixed from this repo.

Verification

Each change measured by a full collection run against a live stack between passes:

state	2xx	failures
baseline	85/180	95
+ id capture + disposable deletes	124/194	70
+ device disposable, - unhelpful ones	124/195	71

All 194 request files validate as YAML.

🤖 Generated with Claude Code