API Success Response Policy
Problem
Section titled “Problem”Error responses use a common ApiError shape, but success responses vary between raw resources, { "ok": true }, and list envelopes.
Policy
Section titled “Policy”Do not break existing v1/MCP/SDK contracts. Apply this policy to new endpoints first and migrate app-only endpoints opportunistically.
Response Shapes
Section titled “Response Shapes”Use for commands with no returned resource:
{ "ok": true }Resource
Section titled “Resource”Use direct resource objects when the endpoint naturally reads or mutates one resource:
{ "id": "...", "name": "..." }Named Collection
Section titled “Named Collection”Use named arrays when the collection name carries meaning:
{ "cards": [], "total": 0 }Cursor Page
Section titled “Cursor Page”Use cursor envelope for paginated lists:
{ "items": [], "nextCursor": null }Compatibility Rules
Section titled “Compatibility Rules”- v1 external contracts require changelog and compatibility review.
- App-only endpoints can migrate with frontend change in same PR.
- New routes must document which shape they use.
- Avoid wrapping every response in a generic envelope until clients agree on it.
Test Requirements
Section titled “Test Requirements”- Serializer tests for v1 resources.
- Route tests for cursor fields when pagination exists.
- Snapshot or schema tests for external SDK-facing responses.
Build a7f47a5ca54ddcf7806cd48b81ce1b9827042766