Summary
The documented response contract for GET /api/categories does not match current production. The public docs show categories as an array of strings, but production returns an array of objects. API clients generated or typed from the documented contract can fail when they treat each item as a string.
Current production reproduction
Verified on 2026-08-10 JST:
curl -sS https://bottube.ai/api/categories
Actual response shape (first item, fields preserved):
{"categories":[{"desc":"AI-generated visual art and creative experiments","icon":"🎨","id":"ai-art","name":"AI Art","video_count":71}]}Public documentation at https://bottube.ai/docs currently specifies:
{"categories":["comedy","music","tech","education","gaming","..."]}The endpoint is also absent from current /api/openapi.json, so clients have no machine-readable schema that corrects the HTML documentation.
Steps to reproduce
- Open https://bottube.ai/docs and expand
GET /api/categories.
- Note that the documented category item type is
string.
- Request https://bottube.ai/api/categories.
- Observe that every category item is an object with
id, name, desc, icon, and video_count.
Expected
The documented contract and production response use the same item type. Prefer documenting the enriched object schema and adding it to OpenAPI, since production and server tests already use it.
Actual
Documentation says string[]; production returns object[].
Impact
This is a functional API contract mismatch: typed integrations based on the public docs can throw at runtime, while generated clients cannot validate the endpoint because it is absent from OpenAPI.
Environment
- Production: https://bottube.ai
- Client: curl / PowerShell Invoke-RestMethod
- Device: Windows desktop
- Authentication: none
Duplicate check
Searched open and closed Scottcjn/bottube issues for /api/categories, “categories response”, and schema terms, plus existing bounty #1102 claims/comments. No report of this response-type mismatch was found. This is a separate root cause from the previously submitted homepage JA localization regression.
Summary
The documented response contract for
GET /api/categoriesdoes not match current production. The public docs showcategoriesas an array of strings, but production returns an array of objects. API clients generated or typed from the documented contract can fail when they treat each item as a string.Current production reproduction
Verified on 2026-08-10 JST:
Actual response shape (first item, fields preserved):
{"categories":[{"desc":"AI-generated visual art and creative experiments","icon":"🎨","id":"ai-art","name":"AI Art","video_count":71}]}Public documentation at https://bottube.ai/docs currently specifies:
{"categories":["comedy","music","tech","education","gaming","..."]}The endpoint is also absent from current
/api/openapi.json, so clients have no machine-readable schema that corrects the HTML documentation.Steps to reproduce
GET /api/categories.string.id,name,desc,icon, andvideo_count.Expected
The documented contract and production response use the same item type. Prefer documenting the enriched object schema and adding it to OpenAPI, since production and server tests already use it.
Actual
Documentation says
string[]; production returnsobject[].Impact
This is a functional API contract mismatch: typed integrations based on the public docs can throw at runtime, while generated clients cannot validate the endpoint because it is absent from OpenAPI.
Environment
Duplicate check
Searched open and closed Scottcjn/bottube issues for
/api/categories, “categories response”, and schema terms, plus existing bounty #1102 claims/comments. No report of this response-type mismatch was found. This is a separate root cause from the previously submitted homepage JA localization regression.