Summary
POST /v1/users/me/access-tokens rejects with an empty body and no JSON error envelope. A bogus rt_, and no Authorization header at all, produce byte-identical responses (HTTP 401, 0 bytes). Every other route in the API returns the standard envelope.
The result: an integrator cannot distinguish "my refresh token is invalid" from "this route is broken."
Repro
# bogus refresh token
curl -sS -o /dev/null -w '%{http_code} bytes=%{size_download}\n' \
-X POST https://cloud-api.near.ai/v1/users/me/access-tokens \
-H 'Authorization: Bearer rt_bogus000000000000'
# -> 401 bytes=0
# no Authorization header at all
curl -sS -o /dev/null -w '%{http_code} bytes=%{size_download}\n' \
-X POST https://cloud-api.near.ai/v1/users/me/access-tokens
# -> 401 bytes=0 (identical)Compare with any other route, which returns 102 bytes of {"error":{"message":"Invalid or expired access token","type":"unauthorized",...}}.
Why it matters
A customer team tried to mint an access token from outside the dashboard so a service could hold a long-lived credential. They tried rt_ in the Authorization header (as the reference specifies), in the body as refresh_token / token / refreshToken, and as a cookie — all empty 401s — and reasonably concluded the refresh flow was broken.
Because the response carries no diagnostic signal, we cannot tell from the outside whether their refresh token was ever valid. That turned a possibly-simple credential problem into an unresolvable one, and it is the last remaining path to a service-holdable usage credential (see linked issue).
Path inconsistency
access-tokens (hyphen) is the deployed route. access_tokens (underscore) appears in doc prose — including the Authorizations note on the endpoint's own reference page and on GET /v1/users/me ("Create via POST /users/me/access_tokens") — and returns 404:
curl -sS -o /dev/null -w '%{http_code}\n' -X POST \
https://cloud-api.near.ai/v1/users/me/access_tokens \
-H 'Authorization: Bearer rt_bogus000000000000'
# -> 404Previously closed #104 used the underscore path, which may be worth a second look given the route has since been renamed.
Ask
- Return the standard JSON error envelope from this route.
- Distinguish a missing credential (401 + message) from an invalid/expired refresh token, so the flow is debuggable from the outside.
- Fix the
access_tokens references in the spec descriptions.
Related: #1056 (no service-holdable credential can read usage; this route is the last remaining path to one).
Summary
POST /v1/users/me/access-tokensrejects with an empty body and no JSON error envelope. A bogusrt_, and noAuthorizationheader at all, produce byte-identical responses (HTTP 401, 0 bytes). Every other route in the API returns the standard envelope.The result: an integrator cannot distinguish "my refresh token is invalid" from "this route is broken."
Repro
Compare with any other route, which returns 102 bytes of
{"error":{"message":"Invalid or expired access token","type":"unauthorized",...}}.Why it matters
A customer team tried to mint an access token from outside the dashboard so a service could hold a long-lived credential. They tried
rt_in theAuthorizationheader (as the reference specifies), in the body asrefresh_token/token/refreshToken, and as a cookie — all empty 401s — and reasonably concluded the refresh flow was broken.Because the response carries no diagnostic signal, we cannot tell from the outside whether their refresh token was ever valid. That turned a possibly-simple credential problem into an unresolvable one, and it is the last remaining path to a service-holdable usage credential (see linked issue).
Path inconsistency
access-tokens(hyphen) is the deployed route.access_tokens(underscore) appears in doc prose — including theAuthorizationsnote on the endpoint's own reference page and onGET /v1/users/me("Create viaPOST /users/me/access_tokens") — and returns 404:Previously closed #104 used the underscore path, which may be worth a second look given the route has since been renamed.
Ask
access_tokensreferences in the spec descriptions.Related: #1056 (no service-holdable credential can read usage; this route is the last remaining path to one).