API v2 — page / limit on GET /sites/{supername}/posts always returns 400 (query params not coerced to number)

Question

GET /sites/{supername}/posts documents page and limit as integers in your OpenAPI spec (https://write.superblog.ai/api/v2/openapi.json):

page   query  integer  default 1
limit  query  integer  default 50

Passing either always returns HTTP 400. The validator expects a JS number, but HTTP query parameters are strings by definition — so no client can satisfy it. Looks like z.number() where z.coerce.number() was intended.

Reproduction

curl -i 'https://write.superblog.ai/api/v2/sites/available/posts?page=2' \
  -H 'Authorization: Bearer <API_KEY>'

HTTP 400:

{"defined":false,"code":"BAD_REQUEST","status":400,"message":"Input validation failed",
 "data":{"issues":[{"code":"invalid_type","expected":"number","received":"string",
 "path":["page"],"message":"Expected number, received string"}]}}

Identical failure for ?limit=10 (path: ["limit"]).

Omitting both returns 200 with the first 50 posts and "totalPages": 21, "totalPosts": 1009 — the server knows there are 21 pages, but there is no way to request page 2.

Already ruled out

- Alternate param names offset, skip, take, cursor, perPage, pageNumber — all silently ignored, always page 1.
- JSON body on GET, and ?input={"json":{"page":2}} — ignored.
- statusFilter and searchTerm work correctly, so the problem is specific to the two numeric params.

Impact

The endpoint returns at most 50 of our 1,009 posts, so we cannot enumerate the site through it. searchTerm caps at 20 results, and the category/tag post endpoints don't accept pagination at all. This is the only listing endpoint in the API, so there is currently no supported way to page through a site's posts.

Sai Krishna · Answer

You were right that this was a coercion problem, though the cause sat one level above the endpoint. Our REST layer was not running the step that converts query strings into the types each endpoint declares, so every integer and boolean query parameter in the v2 API rejected all input. That also explains the two things you noticed while ruling options out: statusFilter and searchTerm kept working because strings pass through untouched, and the alternate parameter names looked ignored because none of them existed to begin with.

It is fixed at the handler level rather than per endpoint, so it applies across the whole v2 API. On the posts list, page and limit now work, as do the isPinned, isFeatured and isPage filters, which were broken the same way.

Worth knowing before you build against it: limit is capped at 200. For your 1,009 posts that is 6 requests rather than 21.

API v2 — page / limit on GET /sites/{supername}/posts always returns 400 (query params not coerced to number)

1 Answer

Login to post an answer