From 70b1b4f177bc7f06201da784f27ba29ad79e75c5 Mon Sep 17 00:00:00 2001 From: "Ronald A. Richardson" Date: Tue, 18 Aug 2026 17:23:21 +0800 Subject: [PATCH] fix: express the two overriding credentials as request-level auth MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit List Organizations and List Network Stores each need a credential the collection-level bearer cannot supply, and each said so with a raw Authorization header. That only overrides collection auth on older Postman CLIs. On 1.47.x the collection auth wins, so both requests went out with the collection credential: GET /v1/organizations 401 {"errors":["Invalid platform API token."]} GET /storefront/v1/stores 400 {"errors":["Stores cannot have stores!"]} Measured on the CI runner, not inferred. A probe ran both requests through the runner's own logged-in CLI against a local echo server with sentinel values, and both fleetops and storefront reported the collection-level bearer on the wire. Independently, curl from the same runner gets 200 from both endpoints with the intended credential, and reproduces both failures exactly when given the collection one. Fixed by expressing the override as a request-level auth block, which is the mechanism Postman actually defines for this, rather than a header that happens to survive on some CLI versions. The mapping form is load-bearing: auth: type: bearer credentials: token: "{{platform_token}}" `auth:` as a LIST is the collection-level shape. Used on a request it makes the request VANISH and aborts the whole run with "items were not found" and 0 requests executed — with or without an `id`, which is the same trap noted in d589105. Measured across six variants; the mapping with `credentials` is the only one that both keeps the request and sends the request-level token. Verified against an echo server: both requests execute, their siblings still inherit the collection bearer, and only these two send their own credential. No folder, ordering, request or assertion changed. --- .../List Organizations.request.yaml | 15 +++++++++++++-- .../Store/List Network Stores.request.yaml | 19 +++++++++++++++---- 2 files changed, 28 insertions(+), 6 deletions(-) diff --git a/postman/collections/Fleetbase API/Organizations/List Organizations.request.yaml b/postman/collections/Fleetbase API/Organizations/List Organizations.request.yaml index 942da6a..5dbb26f 100644 --- a/postman/collections/Fleetbase API/Organizations/List Organizations.request.yaml +++ b/postman/collections/Fleetbase API/Organizations/List Organizations.request.yaml @@ -4,8 +4,19 @@ url: "{{base_url}}/{{namespace}}/organizations" method: GET # This endpoint sits behind the platform API token middleware rather than an # organization API credential, so the collection-level bearer answers 401 here. -headers: - Authorization: Bearer {{platform_token}} +# +# Expressed as a request-level auth block, NOT as a raw Authorization header. A +# manual header only overrides the collection's bearer on older Postman CLIs; on +# 1.47.x the collection auth wins and this request went out with {{api_key}}, +# answering 401 "Invalid platform API token." Measured on the runner. +# +# The mapping form is load-bearing. `auth:` as a LIST is the collection-level +# shape; used on a request it makes the request vanish from the collection and +# aborts the run with "items were not found", with or without an id. +auth: + type: bearer + credentials: + token: "{{platform_token}}" queryParams: limit: "10" diff --git a/postman/collections/Fleetbase Storefront API/Store/List Network Stores.request.yaml b/postman/collections/Fleetbase Storefront API/Store/List Network Stores.request.yaml index 45a6a08..aaf2589 100644 --- a/postman/collections/Fleetbase Storefront API/Store/List Network Stores.request.yaml +++ b/postman/collections/Fleetbase Storefront API/Store/List Network Stores.request.yaml @@ -5,10 +5,21 @@ description: |- This endpoint requires a NETWORK session: authenticate with a network key rather than a store key. A store key is rejected with "Stores cannot have stores!". url: "{{base_url}}/{{api_prefix}}/{{namespace}}/stores" method: GET -headers: - - key: Authorization - value: "Bearer {{network_key}}" - description: A network key. The collection-level store key cannot reach this endpoint. +# A network key. The collection-level store key cannot reach this endpoint. +# +# Expressed as a request-level auth block, NOT as a raw Authorization header. A +# manual header only overrides the collection's bearer on older Postman CLIs; on +# 1.47.x the collection auth wins and this request went out with +# {{storefront_key}}, answering 400 "Stores cannot have stores!". Measured on +# the runner. +# +# The mapping form is load-bearing. `auth:` as a LIST is the collection-level +# shape; used on a request it makes the request vanish from the collection and +# aborts the run with "items were not found", with or without an id. +auth: + type: bearer + credentials: + token: "{{network_key}}" queryParams: query: "" limit: ""