One clean API any online shop plugs into to solve delivery — locations, transport modes, and rates already built in. At checkout, a customer picks a location and sees real ways to get the goods to them, each with a price and a time. No developer ever models Kenya's delivery system from scratch.
This playground runs the real Phase 1 quote logic against Itafika's seed dataset. Change the route and the package — watch the options recompute. This is exactly what a shop's checkout receives.
Tip: try a route nobody serves yet (e.g. an upcountry-to-upcountry pair) to see what a contribution opportunity looks like.
Itafika does for delivery what Daraja did for payments — put a clean interface in front of a fragmented system, and let a generation build on top of it.
Before Daraja, touching M-Pesa meant wrestling the system directly. Daraja hid the mess behind a predictable API — and fintech exploded on top of it.
Itafika asks one question — how can this package get from here to there, and what are the options? — and returns one orderly answer across riders, matatus, buses, and couriers.
The core engine never contains logic for a specific courier. It speaks to small adapters; each translates the standard request for its own world. Adding a provider is a contribution at the edge — never a change to the core. Tap a box to see what it does.
Receives every request in one standardized shape, fans it out to all adapters, collects their answers, and returns a unified list. It knows nothing about any specific provider — that's the whole point. Click any adapter to see its job.
Five endpoints, frozen as the canonical contract in spec/openapi.yaml. Click through them.
Providers each track differently. Itafika normalizes them into one vocabulary, so a shop reads the same five states no matter who carries the package. Advance the shipment.
Itafika only works if the people who depend on it help build it. The most valuable contribution isn't always code. Tap a card.
No code required. Add a stage, hub, or a rate you actually know — the highest-leverage thing most people can do.
spec/data/*.csv, add your row with a source, open a PR. Correcting a stale rate counts just as much as adding one.Teach Itafika one provider. Implement one interface — LogisticsProviderInterface — and the core never changes.
The engine, server, and spec tooling — in TypeScript. Spec-first, so contract changes start in openapi.yaml.
docs/decisions/, keeping the standard and the reference server honest with each other.| provider_id | origin | destination | base_kes | per_kg | time | source |
|---|---|---|---|---|---|---|
| mololine | ZONE_NBI_CBD_01 | ZONE_NKR_MAIN | 400 | 0 | 3 hours | field-2026-06 |
| 2nk | ZONE_NBI_CBD_01 | ZONE_NYR_MAIN | 300 | 0 | 3 hours | field-2026-06 |
Seeded static rates and standardized zone IDs behind the four endpoints; the quote engine returns real, useful numbers. Open-sourced immediately — standardized locations and price estimation are valuable on their own.
In progressPublish LogisticsProviderInterface and invite the community to extend coverage provider by provider — live courier rates, a WhatsApp bot for manual riders, a new town's stage map. The core never changes; the edges grow.
Integrate Daraja / M-Pesa so cash-on-delivery can trigger a split — delivery fee to the rider or SACCO, balance to the merchant. Changes the regulatory posture, so it comes last and with care.
PlannedThe lasting asset isn't the code — it's the open, community-maintained picture of how parcels actually move. Add a rate. Write an adapter. Make delivery something every shop can simply consume.