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:

MethodTypical purpose
GETRetrieve information
POSTCreate a resource or execute an operation
PUTReplace or update a resource
PATCHPartially update a resource
DELETERemove 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.

CodeGeneral meaning
200OK
201Created
202Accepted
204No Content
400Bad Request
401Unauthorized
403Forbidden
404Not Found
409Conflict
422Unprocessable Content
429Too Many Requests
500Internal Server Error
503Service 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.


Did this page help you?