Response Structure
Common response formats used by the SweetConnect APIs
Overview
SweetConnect APIs use shared response formats for successful results and errors. The exact response schema for each operation is documented in the API reference.
HTTP Semantics
SweetConnect APIs follow REST principles and use standard HTTP methods and status codes. Successful requests typically return a status code in the 2xx range, client errors use 4xx, and server errors use 5xx.
The API reference specifies the exact response status and schema for each operation. Some operations, such as file downloads or redirects, use a response format specific to that operation instead of the standard JSON structure.
Success Responses
Successful requests that return JSON usually wrap their result in a data field:
{
"data": {
"id": "resource-id"
}
}Depending on the operation, data can contain an object, an array, or a simple value such as a string, number, or boolean.
List Responses
Operations that return multiple items use an array in the data field:
{
"data": [
{
"id": "resource-1"
},
{
"id": "resource-2"
}
]
}An empty result is represented by an empty array:
{
"data": []
}Paginated Responses
Paginated operations return the items in data and pagination information in a separate meta field:
{
"data": [
{
"id": "resource-1"
}
],
"meta": {
"page": 1,
"offset": 0,
"limit": 10,
"totalItems": 100,
"totalPages": 10,
"hasNextPage": true,
"hasPreviousPage": false
}
}| Field | Description |
|---|---|
page | Current page number |
offset | Number of items skipped before the current page |
limit | Maximum number of items returned per page |
totalItems | Total number of available items |
totalPages | Total number of available pages |
hasNextPage | Indicates whether another page follows |
hasPreviousPage | Indicates whether a previous page exists |
Responses Without Content
Some successful operations return 204 No Content. These responses do not contain a response body.
Error Responses
Errors returned by SweetConnect APIs usually contain an errors array:
{
"errors": [
{
"errorCode": "RequestValidationError",
"message": "The request is invalid.",
"extension": {
"type": "body",
"key": "name"
}
}
]
}| Field | Required | Description |
|---|---|---|
errors | Yes | Contains one or more error objects |
errorCode | Yes | Machine-readable identifier for the error |
message | No | Human-readable description of the error |
extension | No | Additional structured information related to the error |
Applications should use errorCode for programmatic error handling. The text in message is intended for humans and should not be parsed to identify an error. The content of extension depends on the corresponding error code.
Multiple Errors
A response can contain multiple errors, for example when several request fields fail validation:
{
"errors": [
{
"errorCode": "RequestValidationError",
"message": "The name field is required.",
"extension": {
"type": "body",
"key": "name"
}
},
{
"errorCode": "RequestValidationError",
"message": "The languageCode field is invalid.",
"extension": {
"type": "body",
"key": "languageCode"
}
}
]
}Clients should process the complete errors array instead of relying only on its first element.
The API reference lists the documented status codes and error schemas for each operation.