Dashboard API

Automate nearly everything you can do in the Kashier dashboard from your own application. The API is REST-shaped and organized around the main resources, with a few exceptions. This page covers the request, response, and pagination format shared by every endpoint.

Capabilities are enabled per merchant

Seeing an endpoint in these docs does not mean your account can call it. Many Kashier capabilities are gated behind per-merchant feature flags, and a brand-new merchant has only three enabled: multiple balance accounts, payment links, and customers. Everything else is off until Kashier switches it on for your account — you cannot toggle a flag yourself.

If a request fails even though your keys are valid and the path is right, an unenabled capability is a likely cause. There is no single status code for it: some gates reject a disabled capability with a 400, others with a 401 Unauthorized, so do not build a check around one of them.

Two gated capabilities worth knowing about because their pages exist in these docs:

Feature flags are separate from permissions. Even with a capability enabled, each route is additionally checked against the privileges on your user's role — see API keys. Ask your Kashier account manager to enable a capability, and check your role if a call is rejected while the capability is on.

Sample requests

Every method comes with a cURL sample — drop in your own parameters and run it from the command line.

Prefer a GUI? Import the Kashier Postman collection.

Requests and responses

Both request body data and response data are formatted as JSON. The content type for responses will always be application/json.

The success envelope is not uniform across the API. Many v2 endpoints — including the transaction and reporting reads — wrap their result like this:

{
    "body": [object|array], // the result of your request
    "message": [string],    // informational summary. Log it, do not branch on it
    "pagination": [object]  // list endpoints only
}

Others return the result under data instead — { "message": ..., "data": ... }, with pagination alongside it on list reads — and some carry a top-level status. Read the response sample on the individual endpoint's page rather than assuming one shape for the whole API, and code defensively for a result that may arrive under either body or data.

Use the HTTP status code to determine the result of an API call. Where a top-level status field is absent, do not test for one.

Message key

The message key is a string containing a summary of the response. For example, when retrieving a list of transactions, the message might read: The payment transactions has been retreived successfully.

The wording is informational and can change. Do not use it for checks.

Body key

The body key contains the result of your request. It can be an object or an array, depending on the endpoint. For example, a request to retrieve a list of transactions returns an array of transaction rows in body.

{
  "body": [
    { "transactionId": "TX-243585751279", "status": "Approved", "amount": 105, "currency": "EGP" }
  ],
  "pagination": { "total": 715, "page": 1, "limit": 1, "pages": 715, "lastPage": 715 },
  "message": "The payment transactions has been retreived successfully"
}

Pagination

The pagination key provides context for the body key's contents. For example, when retrieving a list of transactions performed by a merchant, pagination parameters can limit the result set.

Request pagination with the page and limit query parameters — page is 1-based, limit is the number of records per page. List endpoints validate their query string strictly: an unrecognized query key is rejected with a 400, so a misspelled or invented parameter name fails the whole request rather than being ignored.

Pagination differs by endpoint in shape, not just in field names. There are two forms, and they are not interchangeable.

Form 1 — a separate pagination key. Used by the transaction and reporting reads shown above: body is the array, and pagination sits beside it.

{
  "body": [ { "transactionId": "TX-243585751279" } ],
  "pagination": { "total": 715, "page": 1, "limit": 1, "pages": 715, "lastPage": 715 },
  "message": "The payment transactions has been retreived successfully"
}

Form 2 — paging fields inside body. Other v2 list endpoints return a paginated document instead: body is an object holding docs plus the paging counters, and there is no pagination key at all.

{
  "message": "Connected-account relationships retrieved successfully",
  "body": {
    "docs": [ { "_id": "6a56a2299bc47f0ac91ae562", "status": "PENDING" } ],
    "totalDocs": 1,
    "limit": 10,
    "page": 1,
    "totalPages": 1,
    "hasNextPage": false,
    "hasPrevPage": false
  }
}

Check whether body is an array or an object before reading paging data, and don't assume pagination exists.

Keys

The Form 2 fields above. Some deployments also emit pagingCounter, prevPage and nextPage; treat them as optional and don't require them.