So, we have been working on a neat piece of art, an API for M-Pesa, named Proxy API.
And we are proud to announce it is ready!
For quite some time, Developers have been trying (and mostly succeeding) in integrating with the First and Second generation M-Pesa APIs (G1 and G2 respectively). It was quite the effort, requiring VPNs and knowledge of SOAP/XML for you to work with the APIs. Well, they are actually great APIs, the most stable,and the most powerful. as long as one was able use them.
Next came Daraja, their new REST/JSON API. Developers were happy that they finally had an easier option to work with, and most decided to try out the new, better option. It was great at first…
Then the issues began.
Most of us have seen complaints of missing callbacks, long Go Live processes, Forms to fill in and upload (in this time and age, imagine that), weird terminology used on the Documentation and API calls, no way to confirm what URLs are registered on their end e.t.c. That list can go on and on. So we decided to do something about it. We decided to create an M-Pesa API that could pretty much fix most of all issues. And that’s where the idea of Proxy API came from.
Proxy API was so named because it was designed to be literally a proxy: simply receiving requests, reformatting into the required XML format for M-Pesa, and forward the request to M-Pesa. But with that option came the capacity to do a lot more.
First, the API was designed to communicate directly with the M-Pesa Broker API, the most stable API and direct entry point into M-Pesa. Secondly, we decided to use REST/JSON to implement the Proxy API interface. This would make it easier to integrate into the API. We also decided, using the knowledge gained from working with Broker, to simplify the API interface facing the developers. Another feature we added was tracing; we could trace requests from developer to M-Pesa and back, then a developer and even business could see what happened when they made a request. Developers could even see the status returned by their services once a callback has been returned or their endpoints called by the API. This would give the developer more control on their integration process and increase the speed with which they integrated into the system.
Then, with tracing requests, came the capability to keep records temporarily for clients to confirm which records or callbacks reached them or not. Clients could place requests to have undelivered callbacks saved and fetched later on demand. Well, this was as long as Broker actually called us too :-).
Thus, the new Proxy API provides the following features:
- Real time logs and callbacks view
- Instant C2B callback URLs (Validation and Confirmation URLs) modification
- Intuitive REST/JSON API interface
- Live support on Telegram, no emails if you want quick answers
- No Go Live forms to fill or process, simply confirm ownership of your shortcode via an API call
- Callback URL testing direct from the Portal
We also have more features in the pipeline for all clients, all building on the simple capability of proxying requests. Please check out the new API at
https://api.proxyapi.co.ke. The documentation for the API is at
https://docs.proxyapi.co.ke/v1/ and we even have an openapi/swagger specification at
Hope you enjoy it!