Conventions for successful responses, errors, and metadata.
The Oquira API follows consistent response conventions across all endpoints. Understanding these patterns will help you integrate more efficiently.
All successful responses include a success flag set to true and a data payload containing the requested information.
When fetching a single resource:
{
"success": true,
"data": {
"id": "srv_7k92m1",
"name": "Customer Service",
"status": "active",
"createdAt": "2024-01-15T08:00:00Z",
"updatedAt": "2024-03-20T10:00:00Z"
}
}When fetching multiple resources, the response includes pagination metadata:
{
"success": true,
"data": [
{ "id": "srv_7k92m1", "name": "Customer Service" },
{ "id": "srv_8n3p5q", "name": "Technical Support" }
],
"meta": {
"total": 45,
"page": 1,
"limit": 10,
"hasMore": true
}
}When no resources match the query:
{
"success": true,
"data": [],
"meta": {
"total": 0,
"page": 1,
"limit": 10,
"hasMore": false
}
}For list endpoints, use these query parameters to paginate:
| Parameter | Type | Default | Description |
|---|---|---|---|
page | number | 1 | Page number (1-indexed) |
limit | number | 10 | Number of items per page (max: 100) |
offset | number | 0 | Alternative: number of items to skip |
curl -X GET "https://api.oquira.com/v1/business/services?page=2&limit=20" \
-H "X-API-Key: your_api_key_here"| Field | Type | Description |
|---|---|---|
total | number | Total number of matching resources |
page | number | Current page number |
limit | number | Items per page |
hasMore | boolean | Whether more pages are available |
When an error occurs, the response includes success: false and an error object with details:
{
"success": false,
"error": {
"code": "VALIDATION_ERROR",
"message": "The provided data is invalid",
"details": {
"field": "email",
"reason": "Must be a valid email address"
},
"timestamp": "2024-03-20T10:00:00.000Z",
"requestId": "req_5f2b8c9d1e"
}
}| Field | Type | Description |
|---|---|---|
code | string | Machine-readable error code |
message | string | Human-readable error description |
details | object | Additional context (varies by error type) |
timestamp | string | When the error occurred (ISO 8601) |
requestId | string | Unique identifier for this request |
Every API request is assigned a unique requestId. This identifier is included in:
X-Request-ID response headerYou can provide your own request ID to track requests across your systems:
curl -X GET "https://api.oquira.com/v1/business/services" \
-H "X-API-Key: your_api_key_here" \
-H "X-Request-ID: your-custom-request-id-123"The API will echo your ID back in the response and logs, making it easier to correlate requests.
Tip: Always log the
requestIdwhen making API calls. It helps our support team diagnose issues quickly.
All API responses include these headers:
| Header | Description |
|---|---|
Content-Type | Always application/json |
X-Request-ID | Unique identifier for the request |
X-RateLimit-* | Rate limiting information (see Rate Limits) |
Cache-Control | Caching directives |
All timestamps in the API follow the ISO 8601 format in UTC:
2024-03-20T10:30:00.000ZWhen sending dates in requests:
2024-03-20T10:30:00Z2024-03-20null explicitly will clear the field[] rather than null