Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

API Integration Service Providers Should Have An API So Their Actions Are Embeddable

DZone's Guide to

API Integration Service Providers Should Have An API So Their Actions Are Embeddable

API integration service providers really need to provide... APIs? Why don't they have those already?

· Integration Zone
Free Resource

Share, secure, distribute, control, and monetize your APIs with the platform built with performance, time-to-value, and growth in mind. Free 90-day trial of 3Scale by Red Hat

During the latest IFTTT flareup, I realized how much I haven't written about my feelings surrounding API integration service providers, iPaaS, or whatever else you call them. Something that always frustrates me in the future, as I am unable to reference my earlier thoughts with a specific URL. So while I am ranting about the lack of APIs for these integration platform as a service (iPaaS) providers, let me add to my list of critical elements I feel are missing from the space: Embeddability!

As a user of your service, provide me an API so I can embed your API recipes into any website, web and mobile application. While the fact that Zapier does have a public API, where IFTTT does not have one at all, the Zapier API doesn't not provide me any access to what API integration recipes (Zaps) are available (ie, core business value). I cannot automatically search for all the Google Spreadsheet integrations. I cannot search for all the Twitter API integrations. Let alone embed the actions enabled by these recipes on any of my website. 

When preparing any list of meaningful actions you can take with APIs, like I did for my university workshop a couple weeks ago, I have to manually go to Zapier, search for actions, and then craft my own link to the detail page (which isn't public BTW). The response from Zapier to why there is no API for this, each time I ask, is that nobody has ever asked for that? Which is starting to smell more and more like business lock-in to me, in the wake of the IFTTT/Pinboard debacle. 

It isn't like the concept of an API driven, embeddable button is anything new. Facebook Share, Twitter Tweet? I just can't buy the fact that nobody has asked for a Run Zapier Zap button? I'm just guessing that folks aren't seeing the embed opportunity, when they are down in the weeds, like the Run in Postman button was. It just takes time for it to happen, a process I am always looking for ways to expedite. ;-)

Anyways. If you are running an API integration service provider, please:

  1. Pay APIs forward by having an API for your platform.
  2. Make all aspects of your service available via API.
  3. Provide embeddable buttons, and linkable hooks at any point in the action.

If you do this, your service will become more than just a destination for discovering and enabling API driven recipes. With a complete API, your platform can become baked into the API enabled fabric of our web, and mobile world(s). As an API integration platform as a service (iPass) provider, it is your responsibility to pay the API concept forward (hear the laughter of my haterz), and not terminate, and capture all the value generated via APIs. The reasons for this are much more than the altruistic visions you may think I'm speaking of, and touch on real world business advantages that you are missing.

Explore the core elements of owning an API strategy and best practices for effective API programs. Download the API Owner's Manual, brought to you by 3Scale by Red Hat

Topics:
integration ,api best practices ,api design

Published at DZone with permission of Kin Lane, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

THE DZONE NEWSLETTER

Dev Resources & Solutions Straight to Your Inbox

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.

X

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}