viaSocket

Search the viaSocket documentation with a natural-language question. Returns the most relevant passages with their page URLs.

Browse the viaSocket API docs, one level at a time. Call it without arguments to get the top level: the modules and pages with a short description and the endpoints they hold. Call it with `path` set to a module's or page's link (or path) to get what is inside it; each listing links the next level. Call it with `path` set to an endpoint's link ending in ".openapi.yml" to get that endpoint as an OpenAPI file: method, url, headers, query params, path variables, a request body example and sample responses. Fetch only the level you need.

Send a POST, PUT, PATCH or DELETE request to any viaSocket API endpoint for the user and return its response: every write (create, update, publish, delete). For GET requests use call_any_read_api_of_viasocket. Look the endpoint up with get_viasocket_api_docs first to get its URL, headers, query params and body, unless the skill or a dedicated tool on this server already gives them exactly. Load the quickstart-viasocket-developer-hub skill first: it explains which tool to use when. Pass the full url with path variables filled in, the headers the docs list, query params in `query` (not in the url) and the JSON body in `body`. For the auth header the docs name (Authorization, proxy_auth_token, x-api-key, ...), pass it with an empty value "": the signed-in user's token is filled in automatically. Never put a real or made-up token there; if the docs name no auth header, leave it out and the token is sent as Authorization. If the API needs the user to sign in, they're asked the first time. Only for the viaSocket endpoints documented on this server: it attaches the viaSocket sign-in, so never use it for Embarko (ship.embarko.ai) or any other service. Returns { status, ok, headers, data }: the HTTP status and the response body, including error details on failure.

List every viaSocket Developer Hub plugin (app) the user's organization owns. Send filter=getAllPlugins and identifier equal to the orgId in the path. Start here to find a pluginId (rowid).

List a plugin's authentication versions (filter=getAuthDetails, identifier=<pluginId>) to find an authid. Responses include decrypted client secrets: never show them to the user.

List a plugin's actions and triggers (filter=getAllActions, identifier=<pluginId>), or get one (filter=getActionDetails, identifier=<actionId>). Use it to find an actionId.

List all versions of an action or trigger (filter=getActionVersions, identifier=<actionId>), with code, inputs, authid, status and verification status. Use fields to keep the response small.

Get run counts, error counts and flow counts for every action and trigger version of a plugin (filter=getPluginDetails, identifier=<pluginId>, optional startTime and endTime dates).

Get the viaSocket organization (id and details) that the signed-in user's token belongs to. Read-only, no inputs. Call this first whenever you need the organization id (orgId) for other viaSocket Developer Hub calls such as List Plugins, Get Plugin or analytics, instead of asking the user for it.

Takes no parameters.

List an organization's embed projects (type=embed) for viaSocket SDK setup. Each data.projects[].id is a project_id (VIASOCKET_PROJECT_ID). Reuse an existing embed: one embed serves a whole product. Only if there is none, create one with the Create Embed Project endpoint (via call_any_api) after the developer confirms.

Read from any viaSocket API endpoint with a GET request for the user and return its response. Use it once you know the exact endpoint: look it up with get_viasocket_api_docs first to get its URL, headers, query params and body, unless the skill or a dedicated tool on this server already gives them exactly. Load the quickstart-viasocket skill first: it explains which tool to use when. For POST, PUT, PATCH and DELETE use call_any_api_of_viasocket. Pass the full url with path variables filled in, the headers the docs list, and query params in `query` (not in the url). For the auth header the docs name (Authorization, proxy_auth_token, x-api-key, ...), pass it with an empty value "": the signed-in user's token is filled in automatically. Never put a real or made-up token there; if the docs name no auth header, leave it out and the token is sent as Authorization. If the API needs the user to sign in, they're asked the first time. Returns { status, ok, headers, data }: the HTTP status and the response body, including error details on failure.

Report a problem to viaSocket while building with it: an error, a confusion, wrong docs or skills, a user correction, or a missing capability. Problems only, never success; no need to ask the user; a failed report never stops the task. Plugs: fix or extend the user's own plugs (the ones in list_plugins) yourself, and build a plug for an app that has none. A plug used in flows but not in list_plugins is viaSocket's: never edit it, report it here (refs.pluginId, refs.actionId; a missing action, trigger or field is kind missing_capability, with exactly what is needed and why). Body: source (sdk | http_api | plug | action | trigger | connection | skill | other), kind (error | confusion | missing_capability | wrong_instructions | user_correction) and feedback (what happened, in plain words), plus optional severity, stage, intent, attempted, expected, actual, error, refs, env and retries. Never include secrets, tokens or script_id. The org and user come from the sign-in.

Call once right after you publish something on the user's own plug (one in list_plugins): a new plug, or a new action, trigger, version or connection on it. viaSocket then reviews the published plug and may add missing actions or triggers. Body: pluginId (the plug rowid, required), published (new_plug | new_action | new_trigger | new_version | connection), plus optional app (the app's name), actionIds (rowids of the actions or triggers just published) and note (plain words, never secrets). No need to ask the user; a failed call never stops the task. The org and user come from the sign-in. Not for problems: use report_feedback for those.

Gets the viaSocket organization's embed signing secret (VIASOCKET_EMBED_SECRET) into the developer's .env encrypted, so you never see it. Use it in SDK setup. Get orgId with get_org_details_by_token first. Before calling, run `docstar-cli key request` in the project folder and pass its publicKey; then run the `save` command this tool returns, then its `emit` command (the developer can choose another .env file). Never ask for, print or repeat the secret.

The app accounts the signed-in user has already connected to viaSocket. Body {} answers rows with auth_id, service_id, service_name and connection_label (a JSON string: parse it before showing it, e.g. the email of the Gmail account). Match service_id to find the auth_id an action or automation needs; if the user has several accounts of one app, ask which. If the app is not there, use create_connection_link.

Takes no parameters.

Make a sign-in link so the user connects an app account (Google, Slack, an API key…) to viaSocket. Body { "service_ids": ["<service_id>"] } answers data[] with a connection_url per app. Give the user the link, wait until they say they signed in, then call list_connections again to get the auth_id. It only makes the link; nothing is connected until the user signs in.

Do one thing in the user's app right now, on their own account: send an email, post a message, add a row, create a record, fetch data. Body { service_id, action_id, auth_id, instructions, thread_id }: service_id from search_apps, action_id from list_app_actions, auth_id from list_connections, instructions in plain words carrying every value (recipient, subject, body, sheet name…), thread_id an id you make up and reuse for retries of the same request. viaSocket's builder turns the instructions into the action's input and runs it; the reply is the app's own result. It acts for real, so say exactly what it will do (which account, which action, which values) and get the user's yes first. For something that should happen repeatedly ("every time", "every morning"), build an automation instead, as the skill describes.

Find an app the user wants to use from their AI: Gmail, Slack, Google Sheets, HubSpot, Notion, Trello or any of 2,300+ apps. Body { "searchquery": "gmail" } answers services[] with service_id, service_name and service_description. This is the first step whenever the user asks to send, read, create, update or search something in one of their apps, or to automate something across apps. The catalog is public: no sign-in needed for this call.

List what an app can do for the user. Body { "serviceId": "<service_id from search_apps>" } (camelCase) answers actions[] with action_id, action_name, action_description and fields_for_action_details. Use it to pick the action that matches the request (Gmail "Send Email", Google Sheets "Add Row", HubSpot "Create Contact") before connecting or running anything. Public catalog, no sign-in needed.

Quickstart for viaSocket: use the user's own apps from their AI (send an email, post to Slack, add a sheet row, read a CRM; any of 2,300+ apps), build automations (flows) across those apps, and for developers: build and manage viaSocket plugins in the Developer Hub, set up a product's viaSocket keys, give a product its own MCP server. Routes plug work through the plug skills index, product integration through the viaSocket skill, and Embarko deploy through Embarko's quickstart. Load this before any viaSocket task. Call this to load the full instructions for this skill before doing the task.

Takes no parameters.