One clean API any online shop can use to orchestrate delivery — locations, transport modes, providers, and rates already built in. At checkout, a customer picks a location and sees real ways to get the goods to them, with clear prices and times. Shops keep customer and order data while Itafika coordinates delivery options and provider handoff state.
This playground shows the Phase 1 quote shape against Itafika's seed dataset. Change the route and the package — watch the options recompute. This is the kind of response a shop's checkout receives from the Worker API.
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 open standards did for transit and maps — put a clean interface in front of a complex system, and let everyone build on top of it.
Standards like GTFS made it easy for apps to show bus and train routes. When everyone uses the same format, it becomes much easier for developers to create useful tools for the public.
Itafika asks one simple question — how can this package get from here to there? — and returns one clear answer across riders, matatus, buses, and couriers.
The core engine is built to handle any courier. It uses small "adapters" to talk to different companies. Each adapter translates the standard request for its own system. Adding a new provider is easy and doesn't change how the core works. 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, set as the official standard in spec/openapi.yaml. Click through them.
Providers each track differently. Itafika puts them into one simple list of statuses, so a shop sees the same updates no matter who carries the package. Advance the delivery.
Itafika only works if the community helps build it. The most important contribution isn't always code. Tap a card.
No code required. Add a stage, hub, or a rate you actually know — this is the most helpful thing most people can do.
source. Phase 2 routes submissions through online moderation into D1 and keeps the open dataset available as a generated public snapshot.Teach Itafika how to talk to a provider. You only need to follow one simple template, and the core code stays the same.
Work on the core engine, the Cloudflare Worker, and API tools. We use TypeScript and follow a spec-first approach.
| 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 |
A Cloudflare Worker reads pre-set rates and standardized location IDs; the engine returns useful options from reviewed data. We are starting with these fixed rates to provide value immediately.
In active developmentWe will invite the community to add more providers — live courier rates, a WhatsApp bot for manual riders, or maps for new towns. The core stays the same while more options are added.
PlannedWe will cover more of Kenya, add more live rates, and improve reliability scores based on actual delivery performance. The system gets smarter and more accurate over time.
PlannedThe most important part of this project is the open, community-maintained picture of how parcels actually move. Add a rate. Write an adapter. Help make delivery easy for every shop in Kenya.