Response format

Successful API responses are JSON. Collection endpoints return arrays at the top level; single-resource endpoints return a single object.

Successful responses

Collection endpoint (GET /organizations/:organization_id/collabs.json):

[
  { "id": "qZmRpL", "name": "Spring lipsticks", "state": "published", ... },
  { "id": "mxKbpQ", "name": "Summer fragrances", "state": "draft",   ... }
]

Single resource (GET /organizations/:organization_id/collabs/:id.json):

{ "id": "qZmRpL", "name": "Spring lipsticks", "state": "published", "brief": "<p>...</p>" }

id values are opaque strings (sqids), not integers — treat them as tokens.

brief-style rich-text fields are returned as pre-rendered HTML and are typically only included on show, not on index.

Error responses

Validation errors (422 Unprocessable Content) use a structured JSON envelope:

{ "errors": { "name": ["can't be blank"] } }

The errors object is keyed by attribute name; each value is an array of human-readable messages.

Authorization and missing-resource responses are less uniform:

• Bearer-token failures (401 Unauthorized) may be header-only or plain text rather than JSON.
• Organization-scoped 403 Forbidden responses, and many organization-scoped 404 Not Found responses, use:

{ "error": "Not authorized" }

• Some user-scoped missing-resource responses return 404 with no body. Example: GET /me/address.json before the user has saved an address.

Content-Type

Use either of these to select JSON:

• Request a .json URL, for example /organizations.json
• Send Accept: application/json

Using both is recommended, but either one is enough.

If you send a JSON request body on POST, PATCH, or PUT, also send:

Content-Type: application/json

Without a .json suffix or Accept: application/json, the same controllers fall back to HTML behavior.

See also

• Pagination
• ETags
• Errors