Feddi Partner API
An identified-retail-decisioning API. Open a checkout session, feed it identity and the basket, and get decisions back. The wallet is one actuator among many.
What Feddi is
Feddi is an identified-retail-decisioning API. It is not a wallet-debit endpoint and it is not a payment shim. You bring a point-of-sale interaction; Feddi resolves who the customer is, what is in their basket, and what to do about it, and returns decisions: item-level offers, precise insufficient-funds recovery, cashback, attribution, and profile enrichment. A closed-loop wallet is one of the actuators those decisions drive, not the center of the system.
The API is designed so the rich path is the obvious path. A partner who only debits a wallet gets a wallet. A partner who feeds Feddi identity, the basket, and context gets intelligence back. Rich in, intelligence out.
Four ideas to internalize first
checkout_session is the spine
Every interaction opens one. Identity, basket, offers, top-up, pay, and the receipt all hang off it. The session is the unit of telemetry, including the things that did not happen.
The wallet is one actuator
Debiting a balance is one thing Feddi can do. Feeding it the basket and identity unlocks decisions: offers, recovery, upsell, attribution, fraud flags.
Feddi never holds money
Balances are a closed-loop ledger the merchant backs (deferred-revenue, "Starbucks stored value"). Every money endpoint is a ledger and reporting surface, never a custody surface.
Two money classes, never conflated
Real money (actual_minor) and promotional credit (promo_*_minor) are distinct. Promo is
locked, expirable, clawback-able, and spent first.
The shape of the surface
The Partner API is ten domains, all assembled in one OpenAPI contract:
| Domain | What it does |
|---|---|
platform | Health, capabilities, OpenAPI self-serve, standalone identify, merchant provisioning, reconciliation. |
checkout_session | The session spine: open, identify, basket revisions, offers, close, abandon. |
auth | API key lifecycle, terminal JWT exchange, sandbox credentials, heartbeat. |
customers | Lookup, identity resolution, cashier-panel summaries, preferences, GDPR, event logging. |
enrollment | OTP signup, cashback claims, identity, consent, anonymous-to-identity merge. |
payments | The single wallet-debit endpoint (promo-first), balance-check, void, refund, QR mint. |
topup | 2-step top-up, reload-bonus grants, SKU top-up, settlement, balance read. |
incentives | Offer feeds, apply / redeem / release, proposals, budget envelopes, points, grants. |
transactions | Transaction detail, void, receipts, disputes, settlements, reconciliation. |
webhooks | Subscriptions, delivery history and retry, the event catalog, a polling fallback. |
What is callable today
This contract is published with honest, per-operation maturity markers. Build against GA and Beta first; everything marked Planned is shape-frozen but not yet mounted.
The 95 Planned endpoints are provisional: their shapes are designed and reserved, not yet
implementation-verified. Wire them, but treat them as not-callable until they flip. The
authoritative, live list of mounted routes is always GET /v1/partner/capabilities and
GET /v1/partner/openapi, never this site alone. See Availability & Maturity.
Where to go next
Quickstart
Your first authenticated call in a few minutes.
The Golden Path
Open → identify → basket → offers → pay → close, worked end to end.
The Decisioning Model
The mental model behind the whole API.
Build with an AI Agent
Your integrator is probably an AI agent. Point it here.
API Reference
Auth, conventions, errors, and all 125 operations.
Money: Actual vs Promotional
The two-class model that runs through every balance.