Everything needed to make the first call, and nothing you have to guess.

Quickstart

Five steps. The first two happen once, in the portal; the last three are the API. Every example below uses the same key id, secret, timestamp and nonce, so the signatures shown are the signatures those inputs actually produce — you can reproduce them before you own a key, and check your signer against them.

1. Step 1

   Create an API key in the portal

   /portal/api-keys → create. Creating a key requires a fresh two-factor code, and the secret is shown exactly once — it is stored encrypted and cannot be displayed again. If you lose it, roll the secret rather than opening a support ticket.

   Three things are worth setting at creation: test mode (see Test mode), the scopes the key may use, and an optional IP allowlist. A key created with no scopes has full access; a key with scopes must hold the one its route declares.

   You receive	Shape	Notes
   key id	26-char ULID	Public. Sent as X-Api-Key and visible in the portal forever.
   secret	44-char base64	32 random bytes. Shown once. Signs every request; never send it in one.

2. Step 2

   Get the product id you are issuing against

   A card is issued against a product — the currency, the fees and the minimum initial load. Products are enabled for your account by us, and there is no endpoint that lists them: ask for the ULIDs of the products enabled for you, or read them off the card-creation form in the portal. This is a known gap in the programmatic surface, not an omission from this page.

3. Step 3

   Register the cardholder

   Cards are issued to a customer in your registry, not to a bag of fields on the issue call. Register the person once with POST /customers, keep the returned id, and issue as many cards to them as you need.

4. Step 4

   Issue the card — the complete signed request

   This script is the whole contract in one place: hash the body, build the canonical string, sign it, send it. It runs as written (bash + openssl + curl); the only things to change are the key id, the secret and the two ids.

   issue-card.sh

   #!/usr/bin/env bash
   set -euo pipefail
   
   BASE="https://business.scarabpay.com/api/v1"
   KEY_ID="01KA7Y2M6Q4RXHB9WD3F5NTC8V"
   SECRET="qZ9m4TbN1sVfK7hLpR2dXwE5yA8cJ3uG6oI0nB4tS1k="
   
   METHOD="POST"
   # PATH is the FULL request path, including /api/v1 — this is the
   # single most common signing mistake.
   REQ_PATH="/api/v1/cards"
   QUERY=""
   BODY='{"product_id":"01KA7XQ8V3ZP5M2CJ9B6TDNF4H","customer_id":"01KA7XR4W9YT6N3DK8C2QFMH5J","amount_minor":2500}'
   
   TS=$(date -u +%s)
   NONCE=$(uuidgen | tr '[:upper:]' '[:lower:]')
   
   BODY_HASH=$(printf '%s' "$BODY" | openssl dgst -sha256 -hex | awk '{print $NF}')
   
   CANONICAL=$(printf '%s\n%s\n%s\n%s\n%s\n%s\n%s' \
     "$METHOD" "$REQ_PATH" "$QUERY" "$KEY_ID" "$TS" "$NONCE" "$BODY_HASH")
   
   SIGNATURE=$(printf '%s' "$CANONICAL" \
     | openssl dgst -sha256 -hmac "$SECRET" -binary \
     | openssl base64 -A)
   
   curl -sS -X "$METHOD" "$BASE/cards" \
     -H "Content-Type: application/json" \
     -H "X-Api-Key: $KEY_ID" \
     -H "X-Timestamp: $TS" \
     -H "X-Nonce: $NONCE" \
     -H "X-Signature: $SIGNATURE" \
     -H "Idempotency-Key: $NONCE" \
     --data-raw "$BODY"

   Reusing the nonce as the idempotency key, as above, is a reasonable default for a one-shot script: both must be unique per attempt. In a real client they differ — the nonce changes on every retry, the idempotency key stays the same across retries of the same intent. That difference is the whole point of idempotency.

5. Step 5

   Handle 201 and 202 differently

   201 means the card exists and is active. 202 means the issuer is provisioning it: the card is pending, and it becomes active later. Poll GET /cards/{card}, or register a webhook and wait to be told. A client that treats 202 as a failure will double-issue.

Authentication

There is no bearer token and no OAuth redirect. Every request is signed with your key's secret, stamped with a timestamp, and spent with a single-use nonce. A leaked bearer token is a standing licence to move money; a signed request is one request.

The canonical string

Seven lines, joined with a single \n, with no trailing newline. The body is hashed rather than included, which keeps the string small and avoids binary ambiguity.

1  METHOD              uppercase: POST
2  PATH                full path, no query, no trailing slash
3  QUERY_STRING        sorted by key; empty string if none
4  X-Api-Key           same value as the header
5  X-Timestamp         same value as the header
6  X-Nonce             same value as the header
7  hex(sha256(body))   lowercase hex; sha256("") if no body

# PATH includes the API prefix.
/api/v1/cards          ✓
/cards                 ✗  the usual first bug

# QUERY_STRING is rebuilt, not copied.
# Sort by key, then urlencode each side:
?per_page=50&cursor=abc
  → cursor=abc&per_page=50

# Repeated params are key[]=v, values sorted:
?status=b&status=a
  → status[]=a&status[]=b

# Spaces encode as + (not %20).
# Empty body hashes the empty string:
e3b0c44298fc1c149afbf4c8996fb924
27ae41e4649b934ca495991b7852b855

A worked example you can reproduce

Feed these exact inputs to your signer. If you get the same signature, your implementation is correct; if you do not, the canonical string is where to look. (The timestamp is long past, so the request itself would be refused — the point is the arithmetic.)

secret       qZ9m4TbN1sVfK7hLpR2dXwE5yA8cJ3uG6oI0nB4tS1k=
method       POST
path         /api/v1/cards
query        (none)
X-Api-Key    01KA7Y2M6Q4RXHB9WD3F5NTC8V
X-Timestamp  1787000400
X-Nonce      f47ac10b-58cc-4372-a567-0e02b2c3d479
body         {"product_id":"01KA7XQ8V3ZP5M2CJ9B6TDNF4H","customer_id":"01KA7XR4W9YT6N3DK8C2QFMH5J","amount_minor":2500}

POST⏎
/api/v1/cards⏎
⏎
01KA7Y2M6Q4RXHB9WD3F5NTC8V⏎
1787000400⏎
f47ac10b-58cc-4372-a567-0e02b2c3d479⏎
97dda525220128a1b9a3e8bbf0e3000b6aab4751cd86df8b427b652729e54062

hex(sha256(body))
97dda525220128a1b9a3e8bbf0e3000b6aab4751cd86df8b427b652729e54062

X-Signature
f2HPicoyBZ26PG1LT6B97MDk/JdbfmUVcUyqDf5vNGg=

The third line is empty because there is no query string. It is still a line — six newlines separate seven fields, always.

The signer, in four languages

Each of these produces f2HPicoyBZ26PG1LT6B97MDk/JdbfmUVcUyqDf5vNGg= for the inputs above. Copy one and move on.

function canonicalQuery(array $params): string
{
    if ($params === []) { return ''; }

    ksort($params);
    $parts = [];

    foreach ($params as $key => $value) {
        if (is_array($value)) {
            sort($value);
            foreach ($value as $v) {
                $parts[] = urlencode((string) $key).'[]='.urlencode((string) $v);
            }
        } else {
            $parts[] = urlencode((string) $key).'='.urlencode((string) $value);
        }
    }

    return implode('&', $parts);
}

function signature(
    string $keyId, string $secret,
    string $method, string $path, array $query, string $body,
    int $timestamp, string $nonce,
): string {
    $canonical = implode("\n", [
        strtoupper($method),
        $path,
        canonicalQuery($query),
        $keyId,
        (string) $timestamp,
        $nonce,
        hash('sha256', $body),
    ]);

    return base64_encode(hash_hmac('sha256', $canonical, $secret, true));
}

import { createHash, createHmac, randomUUID } from 'node:crypto';

function canonicalQuery(params) {
  const parts = [];

  for (const key of Object.keys(params).sort()) {
    const value = params[key];

    if (Array.isArray(value)) {
      for (const v of [...value].sort()) {
        parts.push(`${encodeURIComponent(key)}[]=${encodeURIComponent(v)}`);
      }
    } else {
      parts.push(`${encodeURIComponent(key)}=${encodeURIComponent(value)}`);
    }
  }

  return parts.join('&');
}

function signature({ keyId, secret, method, path, query = {}, body = '', timestamp, nonce }) {
  const bodyHash = createHash('sha256').update(body, 'utf8').digest('hex');

  const canonical = [
    method.toUpperCase(), path, canonicalQuery(query),
    keyId, String(timestamp), nonce, bodyHash,
  ].join('\n');

  return createHmac('sha256', secret).update(canonical, 'utf8').digest('base64');
}

// encodeURIComponent renders a space as %20; the server rebuilds it as +.
// No documented parameter contains a space, but if you ever send one,
// replace %20 with + before signing.

import base64, hashlib, hmac
from urllib.parse import quote_plus


def canonical_query(params):
    parts = []

    for key in sorted(params):
        value = params[key]

        if isinstance(value, (list, tuple)):
            for v in sorted(value):
                parts.append(f"{quote_plus(str(key))}[]={quote_plus(str(v))}")
        else:
            parts.append(f"{quote_plus(str(key))}={quote_plus(str(value))}")

    return "&".join(parts)


def signature(key_id, secret, method, path, timestamp, nonce, query=None, body=""):
    canonical = "\n".join([
        method.upper(),
        path,
        canonical_query(query or {}),
        key_id,
        str(timestamp),
        nonce,
        hashlib.sha256(body.encode()).hexdigest(),
    ])

    mac = hmac.new(secret.encode(), canonical.encode(), hashlib.sha256).digest()

    return base64.b64encode(mac).decode()

# Signs a request with no query string. See the quickstart for
# the full curl call around it.
sign() {
  local method="$1" req_path="$2" query="$3" body="$4"
  local key_id="$5" secret="$6" ts="$7" nonce="$8"

  local body_hash
  body_hash=$(printf '%s' "$body" | openssl dgst -sha256 -hex | awk '{print $NF}')

  printf '%s\n%s\n%s\n%s\n%s\n%s\n%s' \
    "$method" "$req_path" "$query" "$key_id" "$ts" "$nonce" "$body_hash" \
    | openssl dgst -sha256 -hmac "$secret" -binary \
    | openssl base64 -A
}

Scopes

Each route requires at most one scope. A key created without scopes has full access; a key with scopes must hold the exact one its route declares, or the request is refused with 403 out_of_scope — after the signature has been verified, so a caller without your secret still only ever sees a 401.

Read and write are separate on purpose: a reporting integration that only reconciles should hold cards.read and nothing else, so a leak of that key cannot issue a card.

IP allowlists, rotation, revocation

Rolling beats rotating. A roll keeps the key id and overlaps the two secrets for a day, so you can deploy the new secret without a flag day. Rotation mints a new key id, which means every caller has to change two values at once.

Conventions

These hold everywhere, so the operation sections do not repeat them.

Envelopes

Three shapes, and only three. success is present on every response, including errors — branch on it, not on the status code alone.

// one resource
{
  "success": true,
  "data": { … }
}

// a page of resources
{
  "success": true,
  "data": [ … ],
  "meta": { … }
}

{
  "success": false,
  "message": "Insufficient wallet balance.",
  "errors": {
    "balance": ["insufficient_funds"]
  }
}

// errors is {} when there is no
// field-level detail to give.

{
  "success": true,
  "message": "Card issue is processing.",
  "data": {
    "status": "pending"
  }
}

// success-shaped, not an error.
// See Idempotency.

Program against errors, not message. The codes inside it (insufficient_funds, invalid_state) are a stable contract; the human-readable message is not, and may be reworded.

Pagination

Cursor, not offset. Your tables grow while you are walking them, and an offset page shifts under concurrent inserts — so an offset client silently skips rows. A cursor keys off an ordered value, so a page is stable no matter what is inserted behind it.

?per_page=50        # default 20, clamped to 1–100
&cursor="…"        # opaque; from a previous response

# Both are part of QUERY_STRING, so they
# are signed. Sorted: cursor before per_page.

{
  "per_page":        50,
  "has_more":        true,
  "next_cursor":     "eyJpZCI6MjB9",
  "previous_cursor": null
}

Walk forward until has_more is false. Cursors are opaque: pass them back verbatim and never parse or construct one. Every list is newest-first. GET /deposit-addresses is the one list with no meta at all — it is bounded to one address per network, so there is nothing to page.

Idempotency

Three operations move money and therefore require an Idempotency-Key header: issue, recharge and terminate. It is required, not an optimisation — a request without one is rejected before anything happens. The same key is also forwarded to the issuing partner as the client reference, so a retry is deduplicated at both ends rather than only at ours.

// first attempt
{"product_id":"01K…","amount_minor":2500}

// retry, keys reordered → 422
{"amount_minor":2500,"product_id":"01K…"}

When the answer is 202

A 202 on issue, recharge or terminate means the request was accepted and the outcome is not yet known — either the issuer provisions asynchronously, or a response was lost and the platform will not guess. It is success-shaped on purpose: the work is under way and reconciliation will finish it.

Do not retry a 202 as though it failed. Either poll GET /cards/{card} until the status settles, or replay the same idempotency key — which returns the current state rather than starting anything new — or wait for the webhook.

Rate limits

Limits are per API key. Every response carries the current budget, so a well-behaved client never has to guess at one.

Retry-After: 37
X-RateLimit-Limit: 600
X-RateLimit-Remaining: 0

{
  "success": false,
  "message": "Too many requests.",
  "errors": {
    "rate_limit": ["exceeded"]
  }
}

Every authenticated request is logged — method, path, status, source address, and nothing else. No bodies, no headers, no signatures. Those logs are kept for 90 days and then pruned.

Errors

Every error a client can receive, in the order it can happen: the gateway rejects before the operation runs, then validation, then the operation itself. Branch on the code inside errors — those are stable. The message is for your logs and your support team.

1 · At the gateway

These fire before your request reaches an operation. The messages are deliberately terse (Unauthorized., Conflict.) — they give an attacker nothing. The precise reason is in errors.gateway, which is safe to show you and useless to anyone without your secret.

The two 403s only ever appear after a valid signature. That ordering is deliberate: a caller who does not hold your secret can never tell the difference between a key that exists and one that does not.

2 · Validation

HTTP 422, message always Validation failed., and errors is a map of field name → list of human-readable messages (not codes — this is the one place the strings are the detail). Per-field rules live with each operation below.

{
  "success": false,
  "message": "Validation failed.",
  "errors": {
    "customer_id": ["The customer id field is required."],
    "amount_minor": ["The amount minor field must be an integer."]
  }
}

3 · Operation outcomes

4 · Anything else

No error message anywhere in this API names an issuing partner, a partner reference or an internal identifier. That is a deliberate constraint, not an oversight — so when card: [issue_failed] is all you get, the extra detail exists on our side and reaching us is the way to it.

Test mode

A key is created either live or test, and that never changes. A test key exercises the same endpoints, the same signing, the same validation and the same response shapes — against a simulated issuer and a segregated wallet of play money. Nothing a test key does touches a real card, a real balance or a platform report.

{
  "id":      "01KA7Y5T8B2VQD6MJ4H9CFNX3P",
  "mode":    "test",
  "status":  "active",
  "last4":   "4242"
}

Customers

The cardholder registry. A card is issued to a customer, so the person exists in your registry before their first card and is reused for every card after it. Identity fields are encrypted at rest — all except the cardholder's first and last name, which are stored in the clear so our support staff can find a person by name. The registry is scoped to your account either way: another merchant's customer id is a 404, not a permission error.

{
  "first_name":    "Amina",
  "last_name":     "Bello",
  "email":         "[email protected]",
  "phone_number":  "8031234567",
  "dial_code":     "+234",
  "date_of_birth": "1994-03-11",
  "id_type":       "bvn",
  "id_number":     "12345678901",
  "line1":         "14 Adeola Odeku Street",
  "city":          "Lagos",
  "state":         "Lagos",
  "postal_code":   "101241",
  "country":       "NGA",
  "occupation":              "software_engineer",
  "employment_status":       "employed",
  "account_purpose":         "personal_spending",
  "annual_salary":           "4800000",
  "expected_monthly_volume": "150000",
  "terms_of_service_accepted": true
}

{
  "success": true,
  "data": {
    "id":              "01KA7XR4W9YT6N3DK8C2QFMH5J",
    "customer_type":   "individual",
    "first_name":      "Amina",
    "last_name":       "Bello",
    "email":           "[email protected]",
    "phone_number":    "8031234567",
    "dial_code":       "+234",
    "date_of_birth":   "1994-03-11",
    "id_type":         "bvn",
    "id_number_last4": "8901",
    "line1":           "14 Adeola Odeku Street",
    "city":            "Lagos",
    "state":           "Lagos",
    "postal_code":     "101241",
    "country":         "NGA",
    "status":          "active",
    "kyc_status":      "unsubmitted",
    "kyc_failure_reason": null,
    "created_at":      "2026-08-17T21:00:00+00:00"
  }
}

{
  "success": true,
  "data": [ { /* Customer */ }, … ],
  "meta": {
    "per_page":        20,
    "has_more":        false,
    "next_cursor":     null,
    "previous_cursor": null
  }
}

{
  "line1": "9 Ozumba Mbadiwe Avenue",
  "city":  "Lagos"
}

{
  "status": "disabled"
}

{
  "success": true,
  "data": {
    "id":         "01KA7XR4W9YT6N3DK8C2QFMH5J",
    "kyc_status": "pending",
    …
  }
}

Cards

Seven operations: issue, fetch, recharge, freeze, unfreeze, terminate, and list activity. Issue, recharge and terminate move money and require an idempotency key; freeze and unfreeze move none.

┌──── freeze ────┐
                      ↓                ↑
  issue ──→  pending ──→  active  ←── unfreeze ──  frozen
                │          │                        │
                ↓          └──── terminate ─────┬──────┘
             failed                            ↓
                                             terminated

# `expired` is reached by the passage of time, not by a call.
# `pending` and `failed` only ever follow an asynchronous issue.
# `terminated` is final: nothing moves out of it.

{
  "customer_id":  "01KA7XR4W9YT6N3DK8C2QFMH5J",
  "amount_minor": 2500
}

{
  "product_id":   "01KA7XQ8V3ZP5M2CJ9B6TDNF4H",
  "customer_id":  "01KA7XR4W9YT6N3DK8C2QFMH5J",
  "amount_minor": 2500
}

{
  "success": true,
  "data": {
    "id":            "01KA7Y5T8B2VQD6MJ4H9CFNX3P",
    "product_id":    "01KA7XQ8V3ZP5M2CJ9B6TDNF4H",
    "customer_id":   "01KA7XR4W9YT6N3DK8C2QFMH5J",
    "status":        "active",
    "mode":          "live",
    "masked_pan":    "424242••••••1234",
    "last4":         "1234",
    "expiry":        "09/29",
    "currency":      "USD",
    "balance_minor": 2500,
    "created_at":    "2026-08-17T21:00:00+00:00"
  }
}

{
  "amount": 5000
}

422  balance: [insufficient_funds]
422  card:    [invalid_state]
409  idempotency: [in_flight]
202  outcome unknown — see Idempotency

{
  "reason": "stolen"
}

422
{
  "errors": {
    "card": ["termination_blocked"]
  }
}

# A freshly issued card cannot be
# terminated yet. Freeze it and
# terminate later.

GET /api/v1/cards/01KA7Y5T…/transactions
    ?per_page=50

# signed QUERY_STRING (sorted):
#   per_page=50

{
  "success": true,
  "data": [
    {
      "id":           "01KA7Z2M4Q8VXB6DJ3H9CFNT5W",
      "type":         "capture",
      "status":       "completed",
      "amount_minor": 1799,
      "currency":     "USD",
      "occurred_at":  "2026-08-17T20:41:02+00:00"
    }
  ],
  "meta": { … }
}

Funding

Your wallet is funded by stablecoin deposits to a permanent address, one per network. Send to the address, and the deposit is credited to the wallet that pays for card issues and recharges. Withdrawing is not an API operation — see Not in the API.

All three operations are live keys only. A test key receives 403 with Deposits are live-only.: there is no simulated chain to send simulated coins across, so the test wallet is funded for you instead.

{
  "network": "trc20"
}

{
  "success": true,
  "data": {
    "id":         "01KA7ZB6X4NQ2VT8DJ5H3CFMK9",
    "network":    "trc20",
    "asset":      "USDT",
    "address":    "TQ5n…",
    "memo":       null,
    "created_at": "2026-08-17T21:00:00+00:00"
  }
}

{
  "success": true,
  "data": [
    { "network": "bep20", "asset": "USDT", … },
    { "network": "erc20", "asset": "USDT", … },
    { "network": "trc20", "asset": "USDT", … }
  ]
}

{
  "success": true,
  "data": [
    {
      "id":                    "01KA7ZC8M2QVXB4DJ7H5CFNT3P",
      "network":               "trc20",
      "asset":                 "USDT",
      "asset_amount":          "250.000000",
      "credited_amount_minor": 24997,
      "currency":              "USD",
      "rate":                  "0.999900",
      "status":                "credited",
      "tx_id":                 "9f1c…",
      "confirmed_at":          "2026-08-17T20:12:44+00:00"
    }
  ],
  "meta": { … }
}

Webhooks

Register an endpoint at /portal/webhooks — it takes a fresh two-factor code, and the signing secret is shown exactly once, like an API secret. From then on, every event your account produces is POSTed to it as JSON.

There is no per-event subscription: an endpoint receives every event type below, so switch on type and ignore what you do not need. Register several endpoints and each gets its own copy and its own retry schedule.

The delivery

Content-Type:            application/json
X-ScarabPay-Event:       card.issued
X-ScarabPay-Delivery:    01KA7ZD4N8QVXT2BJ6H3CFMK5W
X-ScarabPay-Signature:   t=1787000400, v1=8537115a…

# X-ScarabPay-Delivery is stable across every
# retry of the same delivery — it is the id to
# deduplicate on.

{
  "type":        "card.issued",
  "occurred_at": "2026-08-17T21:00:00+00:00",
  "data": {
    "card_id": "01KA7Y5T8B2VQD6MJ4H9CFNX3P"
  }
}

# Three keys, always. `data` is per event type.

Payloads carry ids and amounts, never the substance of a thing — no card numbers, no cardholder details, no reason strings, no partner references. A webhook is a signal to go and read, so the pattern is: verify, enqueue, return 200, then call the API for the current state.

Verifying the signature

The header is t=<unix seconds>, v1=<hex>, where v1 is an HMAC-SHA256 over the string "<t>.<raw body>" — a literal dot between them — keyed with your endpoint's signing secret. Hash the raw request body, before any parsing or re-serialising: a JSON round-trip changes bytes and breaks the comparison.

secret  Yv8Qk3mR7pTz1LbN5wX2dJ9sH6cF4gA0uE8iO2nB4tS=
t       1787000400
body    {"type":"card.issued","occurred_at":"2026-08-17T21:00:00+00:00","data":{"card_id":"01KA7Y5T8B2VQD6MJ4H9CFNX3P"}}

signed  1787000400.<body exactly as above>

v1      8537115a69c4fb3b86c5b472b5123e527c2dd0c7b4b609ed212fe7962f6df75b

function verifyWebhook(string $header, string $rawBody, string $secret, int $tolerance = 300): bool
{
    $parts = [];

    foreach (explode(',', $header) as $piece) {
        [$k, $v] = array_pad(explode('=', trim($piece), 2), 2, '');
        $parts[$k] = $v;
    }

    if (! isset($parts['t'], $parts['v1'])) {
        return false;
    }

    // Reject a replay of an old, captured delivery.
    if (abs(time() - (int) $parts['t']) > $tolerance) {
        return false;
    }

    $expected = hash_hmac('sha256', $parts['t'].'.'.$rawBody, $secret);

    // Constant time — never ===
    return hash_equals($expected, $parts['v1']);
}

import { createHmac, timingSafeEqual } from 'node:crypto';

export function verifyWebhook(header, rawBody, secret, toleranceSeconds = 300) {
  const parts = {};

  for (const piece of String(header).split(',')) {
    const at = piece.indexOf('=');
    if (at > 0) parts[piece.slice(0, at).trim()] = piece.slice(at + 1).trim();
  }

  if (!parts.t || !parts.v1) return false;

  const age = Math.abs(Math.floor(Date.now() / 1000) - Number(parts.t));
  if (age > toleranceSeconds) return false;

  const expected = createHmac('sha256', secret)
    .update(`${parts.t}.${rawBody}`, 'utf8')
    .digest();

  const received = Buffer.from(parts.v1, 'hex');

  return expected.length === received.length && timingSafeEqual(expected, received);
}

// Express: mount express.raw({ type: 'application/json' }) on this
// route so req.body is the raw Buffer, not a parsed object.

Event types

The complete set. Every amount is integer minor units; every id is a ULID you can pass straight back to the API.

The customer_id on a customer.kyc.* event is the same ULID you pass to POST /cards, so an approval is directly actionable with no lookup. Each of these fires once, on a real change of verdict.

Withdrawals have no API operations but do emit events — they are requested and approved in the portal, and these five let your systems follow along. Note there is no card.transaction event: cardholder spend is read from GET /cards/{card}/transactions, not pushed.

What your endpoint must do

Objects

Every field of every resource this API returns. Anything not listed here is not returned — internal ids, partner references, partner names, full card numbers and security codes are outside the contract by design, not by omission.

Card

Customer

CardTransaction

DepositAddress

Deposit

Not in the API

Four things you might reasonably look for and will not find. Three are deliberate; one is a gap we are naming rather than hiding.