Allan Teng
Hi Bernesto, I'm Allan from the Customer Success Team. Thank you for creating this topic and for posting your ideas on this issue. Great suggestions that will definitely be taken into consideration.
I just wanted to let you know that this is in our pipeline and something that we truly believe in as well. Workato is all about the community and sharing. Apart from being able to share integration recipes that can help solve the greater integration problem, we believe that it is also important for people to also be able to contribute towards building new applications or new triggers and actions on Workato. We are expecting an early version of this to be release early next year. No specific timeline at the moment. But rest assure, our engineering team is working on this.
Once again, thank you!
Allan Teng
Hi Bernesto, I just had a discussion with our team on this and would like to provide an udpate.
Firstly, we are currently building a connector SDK that is plan for release early next year. The connector SDK will allow our partners to create simple connectors to well defined APIs with minimal effort. They will be able to use it for their own use case (account level visibility). To make these connectors public, we will work with the partner to deploy, maintain and support it.
As for the request to make REST calls without creating a connector i.e. a generic REST connector, we do think that this can be useful for the more technically inclined and we want to do this. However, we do not have any concrete plans at the moment. We are hoping that the connector SDK will help alleviate some of these requirements in the short term.
The zapier implementation of webhooks has worked well for me (https://zapier.com/blog/how-use-zapier-webhooks/)
Phuong Nguyen
Patricia Guevarra
Hi Bernesto and Steve,
Sincerely sorry for not getting back to you sooner. We currently have the capability to build connectors through HTTP or SDK. You can check out the following documentation to learn more:
SDK Training: http://resources.workato.com/sdk/#/?_k=6q98w0
Developer Reference Guide: http://developer.workato.com
Developer Console: https://www.workato.com/custom_adapters
Workato Documentation: http://docs.workato.com/
The key differences between HTTP and SDK are as follows:
Let us know if you have further questions!
Still can't find your solution?
Send us a ticket, we will try our best to assist you with your problem
bernesto
Generic Triggers and Actions
I've been evaluating services like Workato for years now, and all have the same purpose, move data from service A to B.
All of them fail miserably; overlooking the mapping of, and transforming of data between 3rd party services. Frequently, these 3rd party services have required specific data, types, formats, etc. that make all but their most basic, useless, interactions impossible (I'm talking about Zapeir and IFTTT). Pointless for the real world.
Workato - You guys have pretty much nailed that "killer feature", the one that actually makes these services viable for real modern businesses. I learned your system in the matter of an hour. Awesome.
But...
There is one GLARING hole in your product. And I say glaring, because it is your Achilles heal. It's usefulness depends on "your" insight into which 3rd party services to add, and what triggers and actions of theirs to implement. Not to mention their is a whole wide custom application world out there that needs data to come in and out of it.
Now... I'm a new user evaluating the product... I may have missed something. Take that for what it is, and this is only positive criticism. I love what you are doing, it just doesn't meet "all" of our needs yet. But, I'm more than a little surprised at the lack of "generic" application triggers and actions. These are the most valuable. They should have been first. The Internet for the (most part) is based on open standards like JSON, XML, HTTP, OAUTH, etc.
So humor me. Why oh why can I not pipe data in and out of generic web standards based endpoints? For example:
AUTHENTICATE MY SERVICE:
* OAUTH
* Basic
* Digest
* Token, key, header, etc.
TRIGGER MY SERVICE:
* Provide a web hook with an object definition (e.g. fields, data format(JSON, XML, name-value, file, etc.)) and on request execute a trigger.
* Poll a service (XML, JSON, RSS, SQL, etc.) and on new items execute a trigger.
ACTION ON MY SERVICE:
* Take the input of a service and map pills to a data format (e.g. name-value, JSON or XML, SQL, etc.), add some headers and HTTP post it to a web hook.
* Take a binary like a file (Drive, Dropbox, etc.) and post it to an endpoint.
Building these integrations would both allow the community to contribute and innovate new recipes with real additive value to your service and organization, while not hobbling power users that have a business use cases and requirements for using obscure service A or API call B.
The value your service offers is not in making services exchange data, but it is in doing so quickly and easily at a lower perceived cost.
4 people like this idea