Pulling Djamo balances, card events and coffre states from outside the app

What is actually behind the account

The reads worth integrating, mapped against where each one originates inside the app, the granularity we can preserve, and what an integrator typically does with it.

Routes we use to reach it

The Djamo build sits on three routes that genuinely apply here. We pick the one that fits the use case and arrange the access plan with you during onboarding — sponsor sandbox, consenting account, or a mixed setup — so the integration ships against the same surface a real Djamo user sees.

Route 1 — Authorized interface integration with protocol analysis

The interface a Djamo customer drives on the phone is the most stable surface for an authorized integration. With the account holder's written consent and an NDA where it is needed, we run protocol analysis against that interface, recover the auth chain (the OAuth-style bearer issued at login plus the cookie/CSRF dance for sensitive actions), and write a clean client against it. Coverage is broad — anything the user can see, the integration can read — and durability is good: the user-facing flow does not break casually. This is the spine for SME bookkeeping, PFM, and any read that depends on coffres or per-card MCC tags. Effort is one to two weeks for a first drop.

Route 2 — User-consented credential access for a specific holder

For builds that only need a single account holder's data — a treasury dashboard for one SME, a personal-finance dashboard for a known user — we run the same client against credentials that the user provides under written consent. We do not store the credentials beyond the active session; tokens are scoped to the consent window. This works well when one consenting holder is the entire universe of the integration. Effort is the shortest of the three.

Route 3 — Native export

The app exposes a statement view and a CSV/PDF download path on the web companion. Where the integration only needs cold history, not live deltas, we wire a scheduled fetch of those native exports and parse them into the normalized schema. Coverage is narrower (no near-real-time card events, no coffre sweeps as they happen) but it is the simplest read.

For a Djamo build we generally recommend Route 1 as the working spine, with Route 3 as the backfill source for long history; Route 2 is the natural shape only when a single end-user is the customer. Picking is a conversation we have once we see the use case.

How the read looks on the wire

The shape below is what an authorized Djamo read tends to look like once the build is done — a cursor-paginated wallet read for delta sync, plus the PI-SPI settlement push as the early-warning channel. Field names and tokens are illustrative, confirmed against the live surface during the build.

# Delta sync against an authorized Djamo wallet read.
# Auth: short-lived bearer issued by the consent flow we set up.

GET /v1/djamo/wallets/{wallet_id}/transactions
    ?since_cursor={opaque_cursor}
    &limit=200
Authorization: Bearer <consent_token>
X-Consent-Id: <scoped consent ref>

200 OK
{
  "wallet_id": "wal_XOF_8f...",
  "currency": "XOF",
  "balance_minor": 254300,
  "items": [
    {
      "id": "tx_01HJ3K...",
      "ts": "2026-05-28T09:14:02Z",
      "type": "mobile_money_in",
      "rail": "wave",
      "counterparty_masked": "***-77-12",
      "amount_minor": 5000,
      "status": "settled",
      "coffre_id": null
    },
    {
      "id": "tx_01HJ3M...",
      "ts": "2026-05-28T09:11:55Z",
      "type": "card_purchase",
      "scheme": "visa",
      "mcc": "5411",
      "amount_minor": -3120,
      "fx_applied": true
    },
    {
      "id": "tx_01HJ3N...",
      "ts": "2026-05-28T09:02:14Z",
      "type": "coffre_sweep",
      "coffre_id": "cof_goal_8s...",
      "amount_minor": -10000,
      "correlation_id": "corr_8s..."
    }
  ],
  "next_cursor": "eyJsYXN0X2lkIjogInR4XzAxSEoz..."
}

# PI-SPI settlement push (BCEAO instant-payment rail).
# Subscribed on our edge, re-signed, and posted to your handler.
POST {your_webhook}/djamo/pi-spi
X-Signature: t=...,v1=...
{
  "event": "settlement.completed",
  "rail": "pi_spi",
  "scheme_ref": "BCEAO-IPS-...",
  "wallet_id": "wal_XOF_8f...",
  "tx_id": "tx_01HJ3K..."
}

What lands in the repo at handoff

The shape of the delivery is built around code that an engineer on your side can run on day one — the OpenAPI specification and the auth-flow notes are in the same drop, but they sit next to the runnable parts, not in front of them.

• Python client covering wallet read, transaction delta sync, card-event normalization, coffre state pulls and mobile-money rail tagging — with retries, cursor-state persistence, and a small CLI to backfill from a chosen date.
• Node.js client with the same surface, packaged for a typical Next.js / Express backend; useful when the integration sits behind an existing TypeScript service.
• Signed-webhook handler for the PI-SPI settlement push, with signature verification, replay protection and a dedupe ring keyed to tx_id.
• Automated test harness — record-and-replay fixtures for every endpoint, plus pytest / vitest suites you can wire into CI. The harness is the part that catches Djamo-side field-shape drift without anyone having to notice.
• OpenAPI/Swagger specification for the surface we expose, plus the auth-flow report covering the bearer issue, the consent token, and how revocation propagates.
• Interface documentation — short, practical: how to wire a new wallet, how to widen the cursor poll, how to add a new mobile-money rail when Djamo adds one.
• Compliance and data-retention notes — what we record about the consent, where the user can withdraw it, and how the system behaves the moment they do.

Sync cadence and freshness windows

Most Djamo builds run a 60-second cursor poll against the wallet/transactions surface. The PI-SPI settlement push acts as the early-warning signal — when it fires we trigger an opportunistic poll rather than waiting for the timer, so a typical transaction lands in your store within two minutes of the user authorising it. Cold history backfills on a separate slower track keyed to the audit window you ask for; we keep it on its own queue so a long backfill never starves the live poll. Deduplication is done at the store layer against tx_id, which means a transaction arriving through both the poll and the push only writes once. Consent-token refresh runs on its own timer keyed to the issued expiry, so a long-running ingestion does not silently lose its read partway through the month.

Posture under BCEAO and FGDR-UMOA

The relevant regime for a Djamo build is the WAEMU banking and microfinance regime supervised by the BCEAO, together with the Djamo Finances licence the company announced in September 2025 (the first Ivorian fintech to receive a BCEAO microfinance licence, per the Ecofin Agency reporting we read). With that licence in place, current accounts and the savings rate the app promotes sit under direct BCEAO supervision, and customer deposits fall under the FGDR-UMOA regional deposit-guarantee scheme.

There is no PSD2-style open-banking regime in UEMOA today. The dependable basis for a third-party read is therefore the account holder's own authorization — written consent, scoped tokens, the ability to revoke at any time — backed by the WAEMU banking uniform act and the BCEAO posture on customer-data handling. BCEAO's interoperable instant-payment platform (PI-SPI), launched 30 September 2025, is the forward-looking interoperability rail and is the route through which the Djamo ledger will see the cleanest cross-bank settlement events. We log every consent, scope the token, document revocation behaviour, and sign an NDA where the integration touches sensitive identity fields.

Things we plan for during the build

• XOF amount handling. The West African CFA franc has no minor unit — one franc is the smallest amount. We carry amounts as integers and tag any FX-applied transaction explicitly (the app does apply a margin on cross-currency merchant payments, per its own disclosure), so a downstream system does not silently double-convert.
• Dual-custodian topology. Djamo holds deposits across Ecobank and BGFIBank, depending on the product. We resolve which custodian backs which wallet during the build and tag every record with the bank-of-record so reconciliations against a partner bank statement line up cleanly.
• Coffre semantics. Coffres are not the current account. Each coffre is its own sub-ledger with a goal, a sweep schedule and an owner — and a coffre sweep is a paired event with the current account. We model it as a first-class object and emit the paired sweep with a shared correlation id so a downstream system never has to guess which debit matches which credit.
• Four mobile-money rails, one shape. Orange Money, MTN MoMo, Moov Money and Wave each carry counterparty references differently. We normalize the four into a single rail-tagged event shape so downstream code never branches on the rail; we keep the original rail reference in a side field for audit.
• Consent lifecycle. The consent token is the read. We refresh it ahead of expiry, write a clear audit trail when it is revoked, and stop reading the moment that signal lands — no silent half-state.

Questions integrators ask before kicking off

How fresh is a Djamo transaction feed once it is wired up?

On the delta-sync route, freshness lands at whatever cadence you ask for — most builds run a 60-second cursor poll against the wallet endpoint and reconcile against the PI-SPI signed-event push, so settled transactions reach your store within a couple of minutes. Older history backfills on a separate slower pass keyed to your audit window.

Does the BCEAO microfinance licence Djamo received in September 2025 change what an integrator can read?

It changes the deposit posture, not the per-user authorization model. The licence puts current accounts and the headline savings rate under BCEAO supervision and brings FGDR-UMOA deposit cover into the picture, but the dependable basis for a third-party read is still the account holder's own consent. We document that consent path in the auth-flow report we hand over.

How are coffre balances modeled separately from the current account in the data we get?

Each coffre is a sub-ledger with its own opening balance, sweep schedule, and goal state. We expose it as a first-class wallet object rather than collapsing it into the parent account. Coffre-to-wallet transfers come through as paired events with the same correlation id so a downstream system can match them without guessing.

Which mobile-money rails come through as identifiable counterparties?

All four of the rails Djamo connects to in Côte d'Ivoire — Orange Money, MTN MoMo, Moov Money and Wave — surface on the transaction as a rail tag plus a masked counterparty reference. We normalize the four into a single shape during the build so downstream code does not need a per-rail branch.

Adjacent apps in the same data corridor

The francophone West African ledger does not begin or end at Djamo. The apps below sit in the same corridor — same users, same rails, same regulator — and an integration that needs cross-app coverage usually picks several of them. We treat them as ecosystem neighbours, not competitors, and have written briefs for several already.

• Wave. Mobile-money rail across Côte d'Ivoire, Senegal and beyond; the cleanest counterparty when a Djamo wallet receives from outside the bank perimeter.
• Orange Money. Pan-African mobile-money provider with deep penetration in francophone markets; a frequent counterparty to a Djamo wallet on both sides.
• Julaya. SME and corporate payments tool from Côte d'Ivoire; useful when an integration needs the B2B side of the same ledger.
• Gozem. Togo / Benin super-app with payments inside; integration shape is similar where the app holds an internal balance.
• Daba. Pan-African investment app; relevant when a portfolio view sits alongside a Djamo wallet on one screen.
• Chipper Cash. Cross-border wallet that touches the same francophone corridor; integration shape rhymes with Djamo's.
• FXKudi. Cross-border transfer service out of Ghana; useful when a Djamo wallet receives from outside UEMOA.
• Bizao. Côte d'Ivoire payment-orchestration layer; relevant when the integration sits behind a merchant rather than a consumer.

What we checked, and what we read

The mapping above draws on the app's own Play listing and support material, Djamo's own product page, the Ecofin Agency reporting on the BCEAO microfinance licence, and BCEAO's own publications on the UEMOA payment-system framework and the September 2025 PI-SPI launch. The specifics on rail coverage come from Djamo's Côte d'Ivoire help centre.

• Djamo — official product page (Côte d'Ivoire)
• Ecofin Agency — Djamo BCEAO microfinance licence (Sept 2025)
• BCEAO — Fintech & digitalisation des services financiers dans l'UEMOA
• Djamo — mobile-money transactions help centre

Reviewed in May 2026 by OpenFinance Lab — Djamo integration mapping.

Working with us on a Djamo build

The runnable source-code drop covers the wallet read, card events, coffre states, and the signed PI-SPI webhook handler — Python and Node.js clients, replay harness, automated tests, and the protocol and auth-flow report. Pricing starts at $300, paid only after you accept the delivery. If you would rather not run the integration yourself, our hosted endpoints sit in front of the same code; call them, pay per call, nothing up front. One to two weeks is the usual cycle for a first drop. Tell us what you need from Djamo