{
"data": {
"id": "usr_123",
"name": "Ada",
"email": "ada@example.com"
}
}A `data` envelope keeps the top-level shape predictable.
Reusable JSON payload shapes for APIs: envelopes, pagination, errors, metadata, partial updates, and event-style messages.
Common shapes for API success and list responses.
{
"data": {
"id": "usr_123",
"name": "Ada",
"email": "ada@example.com"
}
}A `data` envelope keeps the top-level shape predictable.
{
"data": [
{ "id": 1, "name": "Ada" },
{ "id": 2, "name": "Linus" }
],
"meta": {
"page": 1,
"page_size": 20,
"total": 250
}
}A clear `meta` object works well for pagination details.
{
"data": [
{ "id": "evt_1" },
{ "id": "evt_2" }
],
"meta": {
"next_cursor": "eyJpZCI6ImV2dF8yIn0="
}
}Cursor pagination scales better than offsets for some workloads.
Production-friendly payload patterns beyond the happy path.
{
"error": {
"code": "USER_NOT_FOUND",
"message": "No user exists for the supplied id.",
"details": {
"id": "usr_999"
}
}
}Structured errors are easier to handle consistently across clients.
{
"display_name": "Ada Lovelace",
"timezone": "America/Los_Angeles"
}A patch payload should omit unrelated fields unless the API defines another behavior.
{
"event": "user.created",
"occurred_at": "2026-03-27T17:00:00Z",
"data": {
"id": "usr_123",
"email": "ada@example.com"
}
}A common pattern for webhooks, queues, and audit logs.