HTTP actions

Let a workflow act: create a ticket, update a record, or post a message, and use the response in later steps.

An HTTP request step (action:http@1) calls an external API with values from the workflow input and earlier steps. Its response is available to the steps after it. Add it from the Actions group in the Studio's component library, or ask the assistant (“if it's high priority, create an incident in our tracker”).

Actions are deterministic and never count as evaluations: a workflow's cost is still one evaluation per successful intelligence step. A workflow can have up to 10 action steps.

Connections

A connection holds a base URL and how to authenticate there: a bearer token, an API key header, basic auth, or a secret URL (for services where the URL itself is the credential, like a chat incoming webhook). Create them in Workspace → Connections or from the step's inspector.

  • Secrets are encrypted on Kovca's servers before they're stored. They can be replaced but never viewed again, and they never appear in run records, logs, or the assistant.
  • A connection's credentials are only ever sent to its own base URL. With a connection, the step's URL is a path under that base URL; placeholders can't move the request to another host or out of the base path.
  • Changing a connection's URL requires entering its credentials again, so a stored secret is never sent somewhere new.
  • Published workflows reference connections by ID, so replacing a secret takes effect on the next run without republishing. Archiving a connection makes steps that use it fail with CONNECTION_UNAVAILABLE.

Without a connection, the step calls a full https URL without authentication.

Building the request

  • Method: GET, POST, PUT, PATCH, or DELETE.
  • URL or path: placeholders like {{input.ticket_id}} or {{nodes.lookup.output.body.id}} are allowed in the path and query and are URL-encoded. A missing value fails the step.
  • Query parameters and headers: each maps a reference or a fixed value. Missing values are left out. Authorization, Cookie, Host, Idempotency-Key, and similar headers are set by Kovca or the connection and can't be configured.
  • JSON body: the step's input mappings become the body's fields (a.b nests, * sends one value as the whole body). Bodies are limited to 64 KB.

The response

nodes.create_incident.output
{
  "ok": true,
  "status": 201,
  "body": { "id": "INC-1042", "url": "https://incidents.example.com/INC-1042" },
  "headers": { "content_type": "application/json", "location": null, "request_id": "abc123" },
  "error": null
}

JSON responses are parsed, anything else is text, and bodies over 256 KB are cut off (and not parsed). Later steps read fields like nodes.create_incident.output.body.id. The response stays in memory for the run. Kovca never stores it, and the public API returns only each step's status and HTTP status code.

Failures, timeouts, and retries

  • Success is any 2xx status, plus statuses you list under “Also accept” (for example 404 for a lookup).
  • Fail the run (default): an unsuccessful call stops the run with ACTION_FAILED, ACTION_TIMEOUT, or ACTION_DESTINATION_BLOCKED, naming the step in failed_step.
  • Continue: the step succeeds with ok: false and an error of http_status, timeout, blocked, unreachable, invalid_request, or connection_unavailable, so a condition can branch on it.
  • Each attempt times out after 10 seconds by default (up to 15). The whole run still has its 30-second limit.
  • GET, PUT, and DELETE are retried up to 3 attempts in total on network errors, 429, and 5xx (honoring short Retry-After values). POST and PATCH are retried only when you turn that on for the step.
  • Every request carries Idempotency-Key: kovca_<run>_<step>, the same on every attempt. APIs that honor it act at most once, even if a timeout leaves you unsure whether the first attempt went through.
  • A step that times out may still have acted on the other side. Kovca never re-runs a workflow on its own. To retry a whole call safely, send it again with the same Idempotency-Key.

Testing without side effects

In the Studio's Test panel, HTTP steps return the step's sample response by default and nothing is sent, so you can test the whole flow, including what later steps do with the response. Turn on Send real requests to call the real APIs. Steps from simulated tests are marked simulated in the run.

Which destinations are allowed

Kovca calls only https URLs on ports 443 and 8443. It refuses addresses that aren't public (private networks, loopback, link-local, and cloud metadata addresses), checks every address a host name resolves to on every call, and doesn't follow redirects (a 3xx is returned as the response).

Actions vs. webhooks

An HTTP action sends workflow data, whatever you map into it, to a system you choose, as part of the run. An outbound webhook only notifies an endpoint that a run finished, with run metadata and never inputs or outputs. To start a workflow from another service, use a webhook trigger.