DevelopmentBackend
API Structure
RESTful URL patterns, JSON response envelopes, status codes, and pagination standards.
API Structure
All public and internal Nexium Media APIs adhere to standardized RESTful conventions, versioned under /v1/.
Standard Response Envelope
All API endpoints return JSON payloads wrapped in an envelope structure:
{
"success": true,
"data": {
"id": "lead_981a2b",
"clientName": "Dhanbad Steel Works",
"contactPerson": "Rahul Verma",
"email": "rahul@dhanbadsteel.com",
"phone": "+91-9876543210",
"package": "Growth Tier (Web + SEO)"
},
"meta": {
"requestId": "req_01hx8m5z",
"timestamp": 1730362800
}
}{
"success": false,
"error": {
"code": "INVALID_LEAD_PAYLOAD",
"message": "Valid phone number or email address is required.",
"details": []
},
"meta": {
"requestId": "req_01hx8m6a",
"timestamp": 1730362805
}
}HTTP Status Codes
We use semantic HTTP response codes:
| Code | Meaning | Use Case |
|---|---|---|
200 OK | Success | Successful read or update |
201 Created | Resource Created | Successful POST creation (lead submission) |
400 Bad Request | Validation Error | Malformed body or missing required field |
401 Unauthorized | Missing / Invalid Token | Expired JWT or missing Bearer header |
403 Forbidden | Insufficient Permissions | User lacks role to perform action |
404 Not Found | Entity Missing | Resource ID does not exist |
429 Too Many Requests | Rate Limit Exceeded | Client exceeded quota window |
Pagination Standards
For list endpoints, cursor-based pagination is used:
GET /v1/leads?limit=25&cursor=lead_981a2bWas this page helpful?
Let us know how we can make our documentation better.
Edit on GitHub
Last updated on