CreditBook - Digital Khata API integration services

Deliverables checklist

• API specification (OpenAPI / Swagger) for every endpoint we expose
• Protocol and auth-flow report (OTP login, token refresh, request signing, cookie chain)
• Runnable source for login, ledger, statement and stock endpoints (Python / Node.js)
• Automated test suite and Postman / curl examples
• Compliance notes: consent capture, retention windows, data-minimization checklist for SECP / SBP context
• Optional hosted endpoint with per-call metering if you prefer usage-based billing

Engagement models

• Source-code delivery from $300 — you receive runnable API source and full documentation; you pay after delivery once it works for you.
• Pay-per-call API — you call our hosted CreditBook integration endpoints and pay only for the calls you make, no upfront fee; useful for teams that want to skip hosting and ops.
• Both models include a protocol-analysis report so your team understands exactly how the integration behaves.

Customer ledger / statement API

Read a customer or supplier udhaar khata: opening balance, every credit and repayment line with amount, timestamp, note and attached image reference, running balance and due dates. Used for receivables reconciliation, ageing reports and feeding a credit-scoring model with real repayment behaviour.

CashBook cash-flow API

Export CashBook cash-in and cash-out entries by date range and category. Used to build a daily cash position per shop, reconcile till counts, and supply working-capital signals to an inventory-financing engine.

StockBook inventory API

List inventory items with quantity on hand, cost and sale price, and read the quantity adjustments triggered when a bill is created. Used for stock valuation, low-stock alerts in an ERP, and turnover analytics by SKU.

BillBook invoice API

Pull issued invoices and receipts with line items, taxes if entered, customer reference and PDF link. Used to mirror sales into accounting software and to attach proof-of-sale to a financing application.

CreditBook Wallet API

Read wallet balance, top-ups, mobile-load sales and commission earned. Used for activity-based limit decisions, settlement reporting, and reconciling airtime distribution against telco statements.

Reminder & webhook events

Subscribe to events such as “reminder sent”, “payment recorded” or “new ledger entry” so downstream systems update without polling. Used for real-time collections dashboards and to trigger follow-up workflows in a CRM.

1. MSME lender pulls a borrower’s ledger for underwriting

Context: a digital lender wants to extend a working-capital line to a CreditBook shopkeeper. Data / API: customer-ledger statement endpoint plus CashBook export, scoped by a consent token. OpenFinance mapping: the borrower authorizes read-only access (an account-information-style consent), the lender receives a normalised transaction list and ageing summary, and a webhook keeps it fresh until the consent expires.

2. Accounting / ERP sync for a multi-business owner

Context: an owner runs three shops in CreditBook and wants the numbers in their accounting package. Data / API: BillBook invoices, CashBook entries and StockBook valuation, paged by business id. OpenData mapping: a scheduled export job writes journal entries and stock balances into the ERP, replacing manual re-keying.

3. Supplier / distributor portal reads downstream sell-through

Context: an FMCG distributor wants visibility into how fast its goods move at retail. Data / API: StockBook adjustment events and BillBook line items filtered to the distributor’s SKUs, with the retailer’s consent. OpenData mapping: aggregated sell-through feeds demand planning without exposing the shop’s full ledger.

4. Collections dashboard for a micro-finance partner

Context: a partner offering buy-now-pay-later to end customers wants live collection status. Data / API: reminder events plus ledger repayment entries via webhook. OpenFinance mapping: each “payment recorded” event updates the partner’s ledger and recalculates exposure in near real time.

5. Tax / regulatory reporting export

Context: an adviser prepares periodic filings for a cohort of shops. Data / API: BillBook invoices and business-report summaries exported to Excel and PDF on a fixed schedule. OpenData mapping: a documented, consent-backed export keeps the audit trail intact and avoids screenshot-based bookkeeping.

A. Account login (mobile + OTP)

// Step 1: request OTP
POST /api/v1/creditbook/auth/otp/request
Content-Type: application/json
{ "msisdn": "+923001234567" }

// Step 2: verify OTP -> access + refresh token
POST /api/v1/creditbook/auth/otp/verify
{ "msisdn": "+923001234567", "otp": "482915", "device_id": "d-7f3a" }

200 OK
{
  "access_token": "eyJhbGc...",
  "refresh_token": "rt_9b21...",
  "expires_in": 3600,
  "businesses": [ { "id": "biz_01", "name": "Ali Kiryana Store" } ]
}

B. Customer ledger / statement query

GET /api/v1/creditbook/businesses/biz_01/contacts/cust_88/ledger
  ?from=2026-04-01&to=2026-04-30&page=1&page_size=100
Authorization: Bearer <ACCESS_TOKEN>
X-Consent-Id: cns_4421

200 OK
{
  "contact": { "id": "cust_88", "name": "Bilal", "type": "customer" },
  "opening_balance": 12500.00,
  "currency": "PKR",
  "entries": [
    { "id":"e1","ts":"2026-04-03T10:12:00+05:00","type":"credit","amount":3200.00,"note":"flour 2 bags","balance_after":15700.00 },
    { "id":"e2","ts":"2026-04-11T17:40:00+05:00","type":"payment","amount":5000.00,"note":"cash","balance_after":10700.00 }
  ],
  "closing_balance": 10700.00,
  "page": 1, "page_size": 100, "has_more": false
}

C. Webhook: payment recorded

POST https://your-app.example/webhooks/creditbook
X-CreditBook-Signature: sha256=...

{
  "event": "ledger.payment_recorded",
  "business_id": "biz_01",
  "contact_id": "cust_88",
  "entry": { "id":"e2","amount":5000.00,"currency":"PKR","ts":"2026-04-11T17:40:00+05:00" },
  "new_balance": 10700.00,
  "consent_id": "cns_4421"
}

// Recommended handling:
// 1) verify HMAC signature  2) idempotency on entry.id
// 3) on 4xx from your endpoint we retry with backoff (max 24h)
// 4) reconcile nightly via the statement endpoint as a safety net

D. Error handling & limits

401 invalid_token        -> refresh via /auth/token/refresh
403 consent_revoked      -> stop polling, ask user to re-authorize
409 idempotency_conflict -> treat as already processed
429 rate_limited         -> honour Retry-After header
5xx upstream_unavailable -> exponential backoff, then alert

Defaults: page_size ≤ 200, ~5 req/s soft cap per token,
consent TTL configurable (commonly 90 days), all times ISO-8601 with offset.

Regulatory context

CreditBook’s financial activities sit under the Securities and Exchange Commission of Pakistan (SECP), which licenses NBFCs, while payment rails and digital-banking rules fall to the State Bank of Pakistan (SBP). Pakistan’s instant-payment system, Raast, has been moving toward open-API integration and a Person-to-Merchant tier, and the SBP runs a regulatory sandbox for new payment products. Personal-data handling should also be planned against Pakistan’s draft Personal Data Protection Bill, and clients serving Gulf or UK customers may additionally need to satisfy GDPR-style and PSD2-style expectations.

How we keep integrations clean

• Authorized or documented APIs only — no scraping that breaches terms, no credential sharing in the clear.
• Explicit, revocable consent per data scope, with consent ids carried on every request.
• Data minimization: we expose the narrowest field set a use case needs (e.g. ageing summary instead of raw notes where possible).
• Access and consent logs retained for audit; configurable retention and deletion.
• NDAs and security review on request; PII encrypted in transit and at rest in any hosted component.

We are an independent technical studio specialising in App interface integration and authorized API integration. The team has years of hands-on work in mobile apps and fintech — engineers who have built for banks, payment gateways and cloud platforms — and we ship one-stop services from protocol analysis and interface refactoring to OpenData integration, third-party interface integration, automated data scripting and delivery of API documentation.

• Financial and banking apps: transaction records, statement queries, transaction integration
• E-commerce, food-delivery and retail apps: order interfaces, payment integration, data sync
• Hotel, travel and mobility apps: booking interfaces, itinerary queries, payment verification
• Social, OTT media and dating apps: authentication/login, messaging interfaces, profile management
• Full pipeline: protocol analysis → build → validation → compliance handover

Contact

Tell us the target app and what you need — the data, the flows, the volume. We’ll come back with scope, timeline and a quote. Source-code delivery starts at $300 (pay after delivery on satisfaction); pay-per-call hosted API is also available.

Contact page

1. Scope confirmation — which CreditBook data and flows (login, ledgers, cashbook, stock, wallet, webhooks) and your delivery format.
2. Protocol analysis & API design — 2–5 business days depending on complexity.
3. Build & internal validation — 3–8 business days.
4. Docs, samples & test cases — 1–2 business days.
5. First delivery — typically 5–15 business days; third-party approvals can extend timelines.

FAQ

What CreditBook data can you integrate?

How long does delivery take?

How do you handle compliance in Pakistan?

What do I need to provide to start?