channels.action
Run one read or mailbox-draft action on a connected LinkedIn or email account, by registry id (for example linkedin.profile.get, linkedin.people.search, linkedin.inbox.list, email.inbox.list, email.thread.get, email.draft.create). Never sends, posts, invites or changes an account.
| REST | POST /v1/channels/action |
| RPC form | POST /mcp/run with "fn": "channels.action" |
| Scope | pipeline |
| Sandbox key | refused |
| Extra entitlement | none |
| MCP tools | selda_channel_action |
| Internal function | channelActions/api:run |
A free sandbox key is refused: it pulls from a connected outside source and enriches as it goes.
Arguments
| Argument | Type | Required | Notes |
|---|---|---|---|
projectId | string | required | |
id | string | required | |
args | any | optional | |
accountId | string | optional |
What Selda fills in
You never send these. The HTTP layer overwrites them from the API key, which is what keeps one organisation’s data out of another’s reach.
| Argument | Filled in from |
|---|---|
orgId | your organisation, resolved from the API key |
Example request
Required arguments only. Values in angle brackets are yours to fill in; the optional ones are in the table above.
curl -X POST https://api.selda.ai/v1/channels/action \
-H "Authorization: Bearer sk_live_..." \
-H "Content-Type: application/json" \
-d '{ "projectId": "<projectId>", "id": "<id>" }'{
"projectId": "<projectId>",
"id": "<id>"
}The same call in the RPC form
One dispatcher answers both, so this is the same request at a different URL. Use it when you
are already posting to /mcp/*, or for a function that has no path of its own.
curl -X POST https://api.selda.ai/mcp/run \
-H "Authorization: Bearer sk_live_..." \
-H "Content-Type: application/json" \
-d '{ "fn": "channels.action", "args": { "projectId": "<projectId>", "id": "<id>" } }'{
"fn": "channels.action",
"args": {
"projectId": "<projectId>",
"id": "<id>"
}
}Example response
Every endpoint answers in the same envelope, whichever URL you called.
{
"value": <the function's return value>,
"request_id": "req_..."
}The shape of value is not documented here. channelActions/api:run declares no returns validator, so there is nothing to derive it from, and a shape written out by hand here is a shape that goes stale without anything noticing. Call it once against a test key and read what comes back.
On failure the body is { "error": { "type", "code", "message", "request_id" }, "request_id" } and request_id is echoed in the X-Request-Id header.
Generated from convex/lib/mcpRegistry.ts. Nothing in this reference sends: launchRun is in no
registry and never will be, so a script can prepare a campaign completely and a person still
presses send in the app.