Couldn’t find anything on this in the docs… might have missed it… but are there plans to enable this in the near future?
Something like this would require to be able to define a Tulip endpoint to receive some data from a foreign source which would then trigger a workflow to parse the incoming data and e.g. create some table record based on this.
This could be a great way to interface with legacy ERP systems.
No, this would require me to actively trigger the request from some endpoint.
In the case I explained, I am not fetching from a remote endpoint but instead offer an endpoint from Tulip perspective to which some other software would then send the POST request. And finally, receiving this incoming POST request, would trigger an automation workflow to parse the incoming data and make sense of it.
Tulip has never been able to natively parse JSON. It always requires using a Connector function, a Custom Widget, or some extremely precise string parsing if your structure is consistent. I am sure that Pete and Pete from the product team are well aware of this and I would expect JSON parsing to be possible in Automations at some point. It might look something like the new UI when you map MQTT attributes. XML less likely.
Alternatively, if Custom Expressions ever become a thing… there are infinite possibilities. JSON, XML, SOAP, YAML, etc. And the Tulip ecosystem can grow exponentially instead of waiting for feature requests. Just my 2 cents.
@sebme hit the nail on the head, right now we don’t support triggering an automation off an endpoint that customer can hit with a payload that is then handled downstream in the automation.
Calling an automation from some external system is something we are thinking about, but the current focus of the team is continuing to build out the core automations offering.
I see this as two primary asks:
Allow the shape matching to happen within the automation, not on this endpoint - so I can pass it any payload and it will dynamically adjust to support its shape. This is not a pattern we support outside of connectors (and their parse interface). This is probably the bigger mental model shift that we need to seriously consider before implementing.
Allow automations to be called from an api endpoint. The use case is clear here, its just a matter of having the capacity to get this to the top of the priority list.
We are very interested by this future feature, to be able to call an automation with a Tulip endpoint and pass JSON data for automation.
Our use case is for asynchronous integration with our backend system. An update or change in our backend system could be receive in Tulip by this API call and we are able manage the update logic in Tulip with automation step…