Take payments. Keep moving. Grow your way.

Handle checkout, billing and customer tools through APIs and SDKs for web and mobile. The Dime Partner API is organised around REST, uses predictable resource-oriented URLs, accepts JSON request bodies, and returns JSON responses.

Current version: v2. All new integrations should use it. v1 remains available and supported, but will be deprecated.

https://sandbox.api.dimepay.app/dapi/v2

Every production account can enable sandbox mode, so these docs target sandbox throughout. Swap the host for production once your integration is ready.

Every request needs both halves of your API key: the client key in the X-Dime-Client header, and its secret key as a Bearer token.

curl https://sandbox.api.dimepay.app/dapi/v2/invoices \
  -H "X-Dime-Client: ck_your_sandbox_key" \
  -H "Authorization: Bearer sk_your_sandbox_secret"

The secret key is for your server only: keep it out of source control, browsers, mobile apps and anywhere a third party could read it. The client key is the public half and cannot call this API on its own.

Requests without a valid key return 401.

Every resource is identified by its token. Use it wherever you refer to the resource: in a URL, in a request field, as a pagination cursor. Fields that refer to another resource carry that resource's token too. Dime's database ids are never returned and are not accepted.

Every token starts with a three-letter code for the kind of resource, then _. Orders and invoices have an 18-character token that carries the day they were created (in Jamaica), then five random characters: ord_20261112_V1StG, inv_20261112_x9KqL. Every other resource has a 38-character token: the code, then 31 random characters in groups of 8, 8, 8 and 7, every part separated by _, for example txn_V1StGXR8_Z5jdHi6B_myT2x9Kq_Lm3PwRt.

Resources created before this format keep the shorter token they were given, and those tokens stay valid. Treat a token as an opaque string and do not work out a resource's kind from its shape.

Random characters are letters, digits and -; _ only ever separates groups.

A database id sent in a request field is rejected with 400; in a URL it matches nothing and returns 404. This holds for Dime Bridge records too (brq requests, brm linked merchants, btr transfers).

Send plain JSON. Resources come back at the top level, with no wrapper:

{
  "object": "order",
  "token": "ord_20261027_V1StG",
  "status": "PENDING",
  "currency": "JMD",
  "total": 1100
}

Every resource carries an object field naming its type, so a response is self-describing.

Dime uses conventional HTTP status codes: 2xx for success, 4xx for a problem with the request, 5xx for a problem on our side.

Failures return a single error object:

{
  "error": {
    "type": "invalid_request_error",
    "code": "parameter_missing",
    "message": "Currency is required.",
    "param": "currency"
  }
}

type is always one of four values:

param names the offending field where one applies, so an error can be surfaced against the right input in your UI.

List endpoints are cursor-paginated. They return an envelope:

{
  "object": "list",
  "data": [ ... ],
  "has_more": true
}

There is no total count. has_more tells you whether another page exists.

To page forward, pass the token of the last record you received as starting_after:

curl "https://sandbox.api.dimepay.app/dapi/v2/invoices?limit=25&starting_after=inv_20260825_giodw" \
  -H "X-Dime-Client: ck_your_sandbox_key" \
  -H "Authorization: Bearer sk_your_sandbox_secret"

Supplying both starting_after and ending_before is rejected.

Amounts are expressed in the currency's major unit — 1100 in JMD is 1,100 Jamaican dollars, not 11.00.

Supported currencies: USD, JMD, GBP, EUR, TTD, BBD, XCD, GYD, SRD.

Orders enforce a minimum: 200 JMD or 1 USD. Other currencies have no configured minimum.

If you have an existing v1 integration, three things differ:

Plain JSON. v1 signs the request body as a JWT and wraps it in a data field. v2 takes the body directly — sending data is rejected.

No envelope. v1 returns { statusCode, headers, body } with the payload nested under body.response. v2 returns the resource at the top level.

One error shape. v1 returns validation failures as an array of message strings. v2 returns a single error object with a machine-readable code and the offending param.