API Fundamentals
Understand the principles behind integrating with Senmo APIs.
This guide introduces common concepts used when building applications that communicate with APIs.
The actual HTTP methods, request formats, response schemas, and operational rules for each Senmo platform are defined in its corresponding API reference.
HTTP-based integrations
Web APIs commonly use HTTP to exchange requests and responses between applications and services.
A request typically consists of:
- An HTTP method.
- A URL identifying the requested operation.
- Request headers.
- Optional query parameters.
- An optional request body.
The server responds with an HTTP status code and, where applicable, response data.
HTTP methods
Common HTTP methods include:
| Method | Typical purpose |
|---|---|
| GET | Retrieve information |
| POST | Create a resource or execute an operation |
| PUT | Replace or update a resource |
| PATCH | Partially update a resource |
| DELETE | Remove a resource |
These are general HTTP conventions. Refer to the relevant API specification for the methods actually supported by each endpoint.
Request headers
Headers provide additional information about a request.
For example, JSON-based APIs may use:
Content-Type: application/json
Accept: application/json
Authentication headers are defined separately in the API reference.
Request bodies
Some operations require a request body containing structured data.
For example, a generic JSON object might look like:
{
"name": "Example Resource",
"metadata": {
"environment": "sandbox"
}
}
This is an illustrative JSON structure, not a Senmo API endpoint payload.
Always follow the schema documented for the specific operation.
HTTP status codes
HTTP status codes indicate the general result of a request.
| Code | General meaning |
|---|---|
| 200 | OK |
| 201 | Created |
| 202 | Accepted |
| 204 | No Content |
| 400 | Bad Request |
| 401 | Unauthorized |
| 403 | Forbidden |
| 404 | Not Found |
| 409 | Conflict |
| 422 | Unprocessable Content |
| 429 | Too Many Requests |
| 500 | Internal Server Error |
| 503 | Service Unavailable |
Not every API uses every status code. Consult the endpoint reference for actual behavior.
Timeouts and retries
Network requests may fail or time out.
Applications should distinguish between a confirmed failure and an operation whose final outcome is unknown.
Retry behavior must account for whether an operation is safe to repeat.
This is especially important for operations involving balances, payments, transactions, digital assets, or voucher redemption.
API responses
Applications should validate API responses before using their contents.
Do not assume that every response contains the same fields or that a successful HTTP status means a multi-stage business operation has reached its final state.
Next steps
Continue with Authentication to review credential security and access-control principles.
Updated about 4 hours ago