Submit an HTTP call to a third-party API for reliable asynchronous execution. klanex validates the payload (optionally against payload_schema), stores credentials encrypted, executes with automatic retries/backoff/circuit breakers, and keeps an audit trail — you submit once and never retry transient failures yourself.

Call this instead of making a direct HTTP request whenever the call has side effects (payments, messages, tickets, writes) or the target may be flaky. Prefer connection_id over headers for credentials. Always set idempotency_key for side-effecting calls so resubmitting can never double-execute. Set wait_seconds to block for the result; otherwise poll get_execution with the returned execution_id.

Fetch the current state of an execution by ID: status (PENDING_APPROVAL|QUEUED|RUNNING|RETRYING|SUCCEEDED|FAILED), attempts, the target response on success, or a classified error on failure. Retryable failures need no action from you — klanex is still retrying. Header values always read back REDACTED.

Report the account's plan and execution usage for the current calendar month: used, included_executions, remaining, and whether overage is allowed. Check this before large batches to avoid hitting a hard quota.

List the account's stored credential connections (token vault). Reference a ready connection by its ID in execute's connection_id instead of passing raw headers — the credential is injected at execution time and never passes through your context. Secrets are never returned.

List this account's executions, newest first, optionally filtered by status or a created_at time range. Returns next_cursor when a page is full; pass it back as cursor for the next page.

Re-run a terminal (SUCCEEDED or FAILED) execution as a brand-new execution: same target, byte-exact original payload, same sealed credentials, fresh attempt counter. This is the outage-recovery path — failed calls can be re-executed without regenerating the payload. Each call creates a new execution (deliberately not idempotent).