feat(pallet): add the Pallet API collection

[roncodes]

Summary

Adds a Postman collection for the Fleetbase Pallet consumable API — inventory and warehouse management — covering thirteen resources across sixty requests.

products · product-variants · suppliers · warehouses · warehouse-zones · bin-locations
inventory (+availability) · stock-adjustments
purchase-orders (+receive) · sales-orders (+fulfill)
stock-transfers (+approve/ship/receive/cancel) · batches · audits

The Pallet public API is new (fleetbase/pallet PR #4, branch dev-v0.0.2), so there was no prior collection to extend.

Related Issue

Closes #

Type of Change

• Bug fix
• Feature
• Refactor
• Documentation
• Test
• Chore

Implementation Notes

Layout. Local Mode tree under postman/collections/Fleetbase Pallet API, with the legacy single-file placeholder at collections/apis/pallet-api, matching Ledger and Storefront.

A full run builds and tears down its own fixtures. Folders create a product, supplier and warehouse first and capture their public ids, then zones, bins, orders and transfers consume them.

Two things that shape the ordering, both found by running it rather than reasoning about it:

• Deletes are in a Cleanup folder at the end, not at the close of each resource folder. Ending Products with a delete removed the product that the variant, order, adjustment and transfer folders then referenced, and the run failed from that point on with "Product not found".
• Fixture SKUs and warehouse codes carry {{$timestamp}}. pallet_products has a unique(company_uuid, sku) and pallet_warehouses.code is unique outright, so fixed values let the collection succeed exactly once and fail on every run after.

Stock adjustments and transfers address a second, deliberately variant-free product. The API correctly refuses an adjustment on a product that has variants without naming one, so the variant-bearing fixture cannot serve both purposes. Cancel likewise gets its own transfer, since a received transfer cannot be cancelled and one record cannot demonstrate both endings in a linear run.

Baseline assertions run at collection level: 2xx, a JSON body, no error payload, and one Pallet-specific check — that no uuid-bearing key appears in any response. Public ids are this API's addressing scheme, so a uuid on the wire means an internal identifier leaked. That check earned its place immediately: it found product_uuid, variant_uuid, inventory_uuid and warehouse_uuid inside the audit endpoint's meta snapshots, which Pallet's own 245-test suite had missed. Fixed upstream before this PR.

Every request sends Accept: application/json, so a 500 returns a readable error rather than a 1.2MB Ignition page.

Coverage was verified by diff, not by eye: the collection's requests were compared against the routes the application actually registers — sixty for sixty, nothing missing in either direction. The eight PATCH routes are PUT aliases and are documented once, as the other collections here do.

scripts/validate-collections.js asserted an exact count of five collections, which a sixth necessarily fails; bumped to six.

Validation

• Tests
• Lint
• Build
• Manual validation

Run against a local Fleetbase stack (http://localhost:8000) with a real organization API credential:

$ npm run postman:lint
Validated 6 Postman Native Git collections and 3 environments.
Linting Fleetbase Pallet API...
No issues found.  Scanned: 62 | Errors: 0 | Warnings: 0

$ npm run postman:run:pallet -- --environment postman/environments/local.environment.yaml --env-var api_key=…
  requests    62 executed, 0 failed
  assertions  264 executed, 0 failed

Run a second time consecutively to confirm the collection is repeatable:
  assertions  264 executed, 0 failed

Documentation Impact

• No documentation changes needed
• Documentation updated in fleetbase/fleetbase.io
• Documentation needed but not included

The Pallet consumable API is documented in that repo's own README (endpoint table, auth, conventions, worked examples), pinned by a test that compares the table against the registered routes in both directions. A corresponding page in fleetbase/fleetbase.io has not been written.

API Reference Impact

• No API reference changes needed
• Updated fleetbase/postman
• API reference updates required but not included

API reference notes: this PR is the specification update. It should not merge before fleetbase/pallet PR #4, since every endpoint here is introduced there.

Documentation Notes

Worth flagging for whoever picks up the fleetbase.io page: four Pallet resources deliberately refuse writes, and the absence reads as an oversight unless stated. Stock levels have no create/update/delete because stock follows from receipts, fulfilments, transfers and adjustments; adjustments cannot be edited or deleted because correcting one means making another; batches and audit entries are read-only because the system writes them. Transfers follow the same principle with transitions instead of a settable status.

Risk

Low, and confined to this repo — a new collection plus a count constant.

The one ordering dependency is on fleetbase/pallet PR #4. Merging this first would leave a collection whose endpoints do not exist.

Also worth knowing: the API cannot currently put a variant on a stock-transfer line, so a variant-tracked product cannot be transferred. The collection sidesteps it with a variant-free product. That is a Pallet gap, not a collection one, and is being tracked there.

Screenshots / Recordings

Not applicable — no UI changes.