New New: idempotent repayments with client_ref — safe retries for branches on patchy connections Read →
74 Sign in Start free trial

Offline-safe repayments with client_ref

New

Field officers and branches on unreliable connections can retry a repayment without ever double-posting it.

8 min read · Updated 1 Nov 2026

In the field, a request often reaches Zung but the response never makes it back. If your app retries, a naive API would post the repayment twice and the member's statement would be wrong.

How client_ref works

Generate a UUID when the officer captures the transaction and store it with the pending record on the device. Send it as client_ref on /loans/{id}/repayment, /savings/{id}/deposit or /savings/{id}/withdraw.

  • First request: the transaction is posted and tagged with your reference.
  • Any repeat with the same client_ref on the same account returns {"success": true, "duplicate": true} and posts nothing.
curl -X POST https://app.zung.ai/connector/api/banking/loans/4410/repayment \
  -H "Authorization: Bearer $ZUNG_TOKEN" -H "Accept: application/json" \
  -d amount=1500 -d date=2026-11-01 -d payment_type_id=3 \
  -d receipt=QHX7821KE -d client_ref=7f9c2e1a-5b8d-4c3e-9a71-2d6f0b8e4c15

Rules

  • Keep the same client_ref for every retry of one transaction; never reuse it for a different one.
  • Max 64 characters.
  • Treat both success: true and duplicate: true as "done" and clear the item from your offline queue.

Something unclear or out of date? Tell us and we'll fix it.