Get started

Requests and responses

Across the 6 published APIs there is one request shape and one response shape, and knowing them is most of what you need before the first call. This page states what was measured on the published documents, not what the style of the API suggests.

Every operation is a POST with a JSON body

All 356 published operations use POST. There is no GET even for a read: getCardList and getCardLimit are POSTs whose body carries the filter. Treat the verb as fixed and the path as the operation's name.

Nothing is in the query string or the path. No published operation declares a path, query or header parameter — every input is a field in the body.

The shape of any call

POST https://sandboxpub.cms.dgpays.com/SandBox/IntegrationDigitalChannelCredit/credit/api/getCardList
Content-Type: application/json
Authorization: Bearer <access_token>

{
  "channel": "<your channel code>",
  "customerNumber": 1234567
}

The path is the operation.

Operation names are not unique across APIs — changeCardStatus and setCardPin each exist on several — so an operation is identified by its API and its path together. Saying "we call changeCardStatus" does not say which service you call.

Four status codes, declared on every operation

Every one of the 356 operations declares exactly these: 200, 400, 404, 500. A client that handles those four handles every published call.

One request, four possible answers

POST /credit/api/getCardListAuthorization: Bearer …Content-Type: application/json

200The operation ran.Its own response schema
400A rule said no.Error — branch on errorCode
404No such action here.Empty body
500The platform failed.Carry transactionId

200 does not always mean applied.

setCardOperationLimit takes many rows in one call and resolves each independently; the per-row outcome is in the response body, not in the status code. Where an operation takes a list, read the list it returns.

The 400 body is the same object everywhere

Its shape is identical across every published operation, which is why it is worth writing one handler for. The values are not published anywhere in the specifications — see Errors and failures for the 290 codes that are.

Field	What it is
errorCode	The part to match on. Branch on this and nothing else.
message	The error in words, with its arguments substituted in.
messageFormat	The message before substitution — what groups two errors that differ only by their values.
arguments	The values that were substituted into `messageFormat`.
propertyName	Which request field the error is about, where it is about one.
transactionId	The platform's id for this call. Log it; support asks for it.
detail	More than `message` carries, where there is more.
isTechnicalError	Whether the failure was the platform's rather than the request's.

What the specifications do not tell you

These are measured across every published document, and each one has caught a team that assumed otherwise. None of them is a defect you can work around by reading harder — the information is not in the file.

Requiredness is not stated. The required array is a Swashbuckle marker for non-nullable C# value types and is perfectly anti-correlated with nullable. It is not the API's contract. Where this portal says a field is required, a person wrote that down.
Field descriptions carry nothing. Almost all of them are the field name in title case. This portal discards them rather than echoing them back at you.
No document declares a security scheme, so none of them says where the token goes. It goes in Authorization: Bearer, which is what the portal's own try-it panel sends.
Lengths, enumerations and validations are authored, not derived. The specifications carry no maxLength, enum or pattern; what the reference shows was read out of the services' own tables and columns.

Only the sandbox is callable from here.

Each published document declares one server and it is the sandbox. Production addresses are not published on this portal — see Environments.