Summarize this article with:
One connection in viaSocket gives you seven Eden AI actions, from chat to image background removal, all behind the same API key. One of them does something no equivalent step on another platform does. Here is what that means if you are building workflows today.
One connection in viaSocket gives you seven Eden AI actions, from chat to image background removal, all behind the same API key. One of them does something no equivalent step on another platform does.
One step, every model
The Eden AI step in viaSocket works the same way whatever you ask it to do. One action, one model string, one input object. The string reads feature/subfeature/provider, so translation/automatic_translation/deepl and image/background_removal/api4ai are the same call with one field changed.
Switching provider is editing a string. There is nothing to reconnect, nothing new to authorise, and no second integration to maintain when you decide a different engine does the job better.
The answer comes back flat: a status, the provider that ran, the feature, and an output object holding the result. In an automation builder that matters more than it sounds, because it is the difference between mapping a field directly and adding a step to dig it out of a nested structure.
Chat is the one that works differently, and deliberately so. It uses an OpenAI compatible shape with a messages array, which means a prompt written against any other OpenAI style tool transfers without translation.
viaSocket covers the whole surface, chat included
Worth saying plainly, because it is not the usual outcome. Most platforms that wire up an AI gateway expose the straightforward calls and stop before the awkward one, and chat is always the awkward one: the request is not a single text field, it is a conversation, and the response carries structure the other actions do not.
viaSocket exposes all of it. Seven actions, chat included, and we checked each one against real traffic rather than taking it on trust. They then went back over their own wording so that the interface describes what the step actually does, which is the part most integrations skip.
The result is that you are not building around a partial integration, and nothing in their interface describes behaviour you will not find.
The seven actions, and what each one maps to
| Action in viaSocket | What it does | Eden AI model string |
|---|---|---|
| Chat Conversation | Any chat model, one step | provider/model |
| Translate Text | Translate a field in flight | translation/automatic_translation/provider |
| Text to Speech | Turn a message into audio | audio/tts/provider |
| AI Generated Content Detection | Score how likely a text is machine written | text/ai_detection/provider |
| Remove Background of an Image | Cut a subject out of a photo | image/background_removal/provider |
| Face Detection | Find faces and landmarks in an image | image/face_detection/provider |
| List Models | Read the live catalogue inside a running workflow | no model string, it returns them |
List Models is the one worth your attention
Six of those seven actions exist in some form on most automation platforms. The seventh does not, and viaSocket built it.
List Models asks Eden AI which models are currently available and hands the answer back into the workflow. That sounds administrative until you look at what it removes. On every other builder, the model you use is chosen when you draw the workflow, typed into a field, and frozen there. When that model is retired, or renamed, or a cheaper one ships, the workflow keeps calling the old string until something breaks loudly enough for someone to notice.
With List Models in front of the step, a workflow can read the catalogue at run time and pick from what actually exists at that moment. A scenario nobody has opened in four months stops being a scenario built on a guess made in April.
We built that flow on viaSocket to check it was real rather than plausible: a trigger, List Models, a translation step using what came back, and a Slack message at the end. The catalogue came back complete, field for field identical to our own, and the translation step that followed it ran on what it had just been handed. It works, and it is the reason this integration is worth writing about rather than listing.
Start from a template rather than a blank canvas
The other thing viaSocket did well is ship the examples. Their own guide walks through complete workflows rather than describing the step in the abstract, with ready-made templates for the tools most teams already live in: Gmail, Slack, Google Docs and Salesforce.
That matters more than it sounds. The hard part of an AI step is rarely the model, it is deciding where it sits in a process that already works. A template answers that question for you, and you adapt it rather than designing it.
Their walkthrough is here: Eden AI Automation: Use Cases, Templates and How to Set It Up.
Starting from here
The Eden AI connection in viaSocket takes one API key and covers all seven actions. Nothing is per provider, so switching from one translation engine to another, or trying a different chat model, is a field edit rather than a new integration.
Our integration page lists what the step covers and links the ready made templates: edenai.co/integrations/viasocket. Keys are free to create at app.edenai.run, and the model strings used above are documented in full in the Eden AI docs.
