I’m getting more emails and DMs from startups doing what I’d consider to be integration platform as a service (iPaaS) solutions. These are services that help developers or business users integrate using multiple APIs. Think IFTTT or Zapier. I’ve seen many waves of them come, and I’ve seen many waves of them go away. I’m always optimistic that someone will come along and make one that reflects my open API philosophy and still can make revenue to support itself. So far, Zapier is the closest one we have, and I”m sure there are others, but honestly I’ve grown weary of test driving new ones, and I am not as up to speed as I should be on what’s out there.
When it comes to iPaaS providers the bar is pretty high to convince me that I should be test driving your solution, and why I should support you in the long run. This is partly from just having supported so many services over the years, only to have them eventually go away. It is also because of new problems for consumers being introduced into the mix because of the abstracting away of the complexities of APIs, rather than joining forces to educate and fixes these complexities amongst API providers. I’m always willing to talk with new iPaaS providers that come along, but I have a few requirements I like to put out there which usually filters the people who end up reaching out and engage from those who do not.
- Due Diligence – Make sure you are testing driving and reviewing as many existing iPaaS platforms as you possibly can, because there are a lot of them, and the more you kick the tires on, the more robust and valuable your solution will be.
- API Definitions – Your solution needs to be API definition driven, adopting OpenAPI, Postman collections, and existing formats for defining each of the APIs you are integrating with, as well as mapping between multiple services.
- API Extensions – If the existing API definitions do not deliver what you need to sufficiently map your integrations then learn how to extend them, augment them, and work to evolve the existing specifications to meet your needs.
- Visualized Experience – Most of the new iPaaS providers I am talking with are focused on providing slick new visual tooling for defining integration—which I fully support but do not unnecessarily abstract away what really happens behind.
- Quick Code View – iPaaS tools should work for business users and developers, allowing both to easily click “view source” and see what is happening behind the scenes, being able to view either the code or artifacts behind each integration.
- Work With API Providers – Reach out and build relationships with the API providers you are build on top of. You won’t be able to in all cases but you should try to reach out to them and establish some sort of relationship with your supply chain.
- Have An API – Do not build your business on top of APIs and not publish your own API. This is an unforgivable sin in my book, and will mean that you never quite see eye to eye with your API providers or your API consumers.
- Licensing – Don’t be locking up workflows in some restrictive licensing, keeping everything open, sharable, and reusable across the API economy.
That is my shortlist when it comes to what I need to see when you are building your iPaaS platform. I have plenty of other requirements, but this should let folks pre-filter before reaching out to me. So far, the ones I spoke with are meeting these requirements. However after talking with my co-worker Trent McCann, the Engineering Manager for Quality at here at Postman, and he had some opinions. For the record Trent has “lots of thoughts (opinions), not always valid but I tend to share them none the less”—regardless, I fee like they needed stating:
- Back in the day when WYSIWYG editors rolled onto the scene, they would put in all kinds of garbage code, even though it was never needed. So messy to look at and do anything with manually. Hate to see something like this happen again, just in another form.
- You end up in ecosystems where you are totally at the mercy of the vendor. There is no code or little code to work in and even if there is, you may not have people with the skill sets to do much with it.
I agree 100%. I’d say the abstracting away of the API experience can begin to have a negative impact just like the WYSIWYG world as Trent points out. We need more web literacy. We need more API literacy. We need cleaner APIs from API providers. We DO NOT need garbage abstracted away, or as Trent says generated as part of new integrations with APIs—there is too much garbage out there already. Trent is spot on when it comes to his concerns. We need more investment in API providers delivering high quality easy to use APIs, and we need more investment in API consumers who are aware of common practices, while still also providing high quality visual / UI based services and tooling for integrating and daisy chaining APIs together.
If you are building a new iPaaS solution feel free to reach out—if you want to hear my thoughts that is. If you don’t, I understand, feel free to email or tweet your solution at me and I”ll add to my queue of services to test drive at some point. I wish you the best o luck in your work. Also, I recommend also taking a look at Postman collections, as well as Postman runners and monitors, and think about how you can incorporate these existing mechanisms into your work. Partly it is my job to recommend you do this, but mostly it is because we have 8M+ developers you can tap when it comes to delivering your integration solution. If your solution is already Postman collection defined, using the machine readable definition as a unit of compute in your API integration workflow, you are going to immediately be useful to our developers right out of the gate, which will help with that adoption curve of yours, which is always one of my biggest concerns with new iPaaS providers.
This article originally appeared here.