> ## Documentation Index > Fetch the complete documentation index at: https://docs.reliantlabs.io/llms.txt > Use this file to discover all available pages before exploring further. # SDK API reference > Every remote procedure in Reliant's public API, which Go SDK method wraps it, and what the SDK deliberately leaves out Reliant's public API is a deliberately small slice of its full API: 22 procedures across six services, all in the `reliant.v1` package and all served over [Connect](https://connectrpc.com/). This page lists them. The Go SDK wraps each in a method, and its generated clients contain exactly these procedures and no others, so a procedure that is not here cannot be called through the SDK, whatever token you hold. > [!NOTE] > > This page is written by hand from `proto/public-api.txt` in the [Reliant repository](https://github.com/reliant-labs/reliant), the file that decides what is public. It is not generated yet, so it can fall behind that file. A generator that writes it from the public descriptors is planned. When this page and the file disagree, the file is right. A request names a procedure by its path, `/reliant.v1./`, and carries the token as `Authorization: Bearer rlat_…`. Most code should use an SDK rather than building requests by hand, but any Connect or gRPC client generated from the public definitions can call these. ## Runs `RunService` is fully public. A run is one execution of a workflow. | Procedure | Go method | What it does | | - | - | - | | `StartRun` | `Runs.Start` | Starts a workflow and returns at once with the run, which is pending or active. A message is optional. | | `GetRun` | `Runs.Get`, `Runs.Nodes` | Returns one run's current state, with its node executions. | | `ListRuns` | `Runs.List` | Lists runs, newest first, narrowed by workflow, display state, trigger, launch kind, time window, title and more, and paged by token. With a session or parent id it lists that session's runs or that run's children. | | `LastRunPerWorkflow` | `Runs.LastPerWorkflow` | Returns the most recent root run of each workflow you have run, one per workflow. | | `SignalRun` | `Runs.Signal` | Delivers messages to a run that is already going. It never starts one. `delivered` is false when the run was not live. | | `CancelRun` | `Runs.Cancel`, `Runs.CancelWithResult` | Hard-stops a run. There is no position to resume from afterward. | | `PauseRun` | `Runs.Pause`, `Runs.PauseWithResult` | Parks a run, which stays live and resumable. **Beta.** | | `ResumeRun` | `Runs.Resume`, `Runs.ResumeWithResult` | Continues a paused run from where it stopped. **Beta.** | | `InterruptRun` | `Runs.Interrupt` | Cancels the in-flight model call and executing tools and parks the run, without ending it. **Beta.** | `Runs.Follow`, `Runs.FollowSession`, `Runs.Status` and `Runs.StatusSession` are not procedures of their own. They are built from the reads below (`GetRun`, and the chat and workflow-execution reads) and add the verdict logic, which is why they are the better way to ask whether a run succeeded. A `Run` has a lifecycle (`state` and `stop_reason`), an `outcome` the workflow declared for itself, and a `display_state` that folds them into the one word a person reads. The `display_state` is one of `QUEUED`, `RUNNING`, `NEEDS_INPUT`, `PAUSED`, `COMPLETED`, `FAILED`, `CANCELLED` or `WAITING_FOR_MACHINE`. A run that completed with outcome `failure` has `COMPLETED` for its display state, so check the outcome too; [the Go guide](https://docs.reliantlabs.io/sdk/go.md#did-it-succeed) explains. ## Triggers `TriggerService` is partly public. Reading a trigger and firing it are; changing what runs unattended is not. | Procedure | Go method | What it does | | - | - | - | | `GetTrigger` | `Triggers.Get` | Returns one trigger with its next fire time and most recent firing. The method also finds a trigger by name. | | `ListTriggers` | `Triggers.List` | Lists your triggers, optionally for one project. | | `FireTrigger` | `Triggers.Fire` | Runs a trigger now, outside its schedule, skipping the enabled and overlap checks. The firing is asynchronous: the response carries an id to find its event by. | | `ListTriggerEvents` | `Triggers.Events` | Lists a trigger's firings, newest first, paged by cursor. Each launched firing carries the state of the run it started. | | `GetLaunchEvent` | `Triggers.LaunchEvent` | Returns the event that launched a session: its kind, and for a schedule the scheduled slot. | Delivering to a webhook trigger is not one of these procedures. It is a plain HTTP `POST` to `/hooks/{trigger id}` with the trigger's own credential, which the Go SDK's `NewWebhook` sends. See [Webhooks](https://docs.reliantlabs.io/automations/webhooks.md). ## What following a run needs A run's progress is the update feed of the session it lives in, and its open gates are that session's questions and approvals. The SDK reads them to follow a run, list its gates and answer a question. None of these is a general chat API. | Procedure | Go method | What it does | | - | - | - | | `ChatService/GetChatUpdates` | Used by `Runs.Follow` | Fetches a session's updates since a sequence number. | | `ChatService/GetWorkflowExecutions` | Used by `Runs.Follow`, `Runs.Status`, `Gates.Pending` | Returns the session's tree of workflow executions. | | `QuestionService/ListPendingQuestions` | `Gates.Pending` | Lists the pending questions in a session, oldest first, each naming the thread that asked. | | `QuestionService/ResolveQuestion` | `Gates.Answer` | Answers a pending question. | | `ApprovalService/ListApprovalsByChat` | `Gates.Pending`, `Approvals.List`, `Approvals.ListForRun` | Lists a session's approvals. Reading only. | ## Inbox `InboxService` is partly public: you can read the inbox and hide or restore items, but not act on the machine-storage items it lists. | Procedure | Go method | What it does | | - | - | - | | `InboxService/ListInbox` | `Inbox.List`, `Inbox.Counts` | Lists what is waiting on you, blocking items first. With a limit of zero it returns only the counts, which is what `Counts` asks for. | | `InboxService/DismissInboxItem` | `Inbox.Dismiss` | Hides items from your inbox. It does not resolve an approval or a question. | | `InboxService/RestoreInboxItem` | `Inbox.Restore` | Undoes a dismissal. | ## Which token scope each procedure needs Reliant enforces [token scopes](https://docs.reliantlabs.io/sdk/overview.md#scopes) on every call. A token with `reliant:api` may call any procedure on this page. A narrow token may call only these: | Scope | Procedures | | - | - | | `runs:read` | `GetRun`, `ListRuns`, `LastRunPerWorkflow` | | `runs:start` | `StartRun`, and what `runs:read` allows | | `runs:control` | `SignalRun`, `PauseRun`, `ResumeRun`, `CancelRun`, `InterruptRun`, and what `runs:read` allows | | `triggers:fire` | `FireTrigger` | Every other procedure on this page, including the trigger reads, the chat reads, the questions, the approvals and the inbox, needs `reliant:api`. A narrow token that calls one is refused with `PermissionDenied` (`scope_missing`). ## What is not public `proto/public-api.txt` classifies every service in `reliant.v1`, and nothing becomes public by default: a test fails when a service is left unclassified. The following are never public, and the test refuses them even if someone lists them. | Withheld | Why | | - | - | | Enabling, disabling, creating, updating or deleting a trigger (`EnableWorkflow`, `DisableWorkflow`, `SetTriggerEnabled`, `CreateTrigger`, `UpdateTrigger`, `DeleteTrigger`) and `RotateWebhookToken` | They decide whether an automation runs at all, as whom and where. The `triggers:manage` scope guards them on the server; see [scopes](https://docs.reliantlabs.io/sdk/overview.md#scopes). | | Approving or denying (`Approve`, `Deny`, `BatchApprove`, `BatchDeny`) | An approval means a person said yes. | | Minting tokens (`TokenService`) | A token never mints a token. | | Binding a chat to a machine (`SetChatDaemon`), the inbox's machine-storage actions (`CleanupStorage`, `ForgetStorageWorktree`) and every service a machine uses to talk to Reliant | They wire up or change infrastructure, not your code. | Every other service in the API, such as projects, workflows, settings, connections and usage, is not part of the first public surface. The set grows additively. When a procedure is added it appears here and in the SDK, and nothing listed on this page is removed within `reliant.v1`. ## The TypeScript SDK `@reliantlabs/sdk` generates its own, smaller set, for the streams a frontend renders. It is `StreamingService` (`StreamUserUpdates` and `StreamChatUpdates`), `BackgroundService/StreamProcessOutput` and `ChatService/SendMessage`. These are not in the Go list above, because a chat stream is how a UI shows a conversation rather than how a program drives a run. [The TypeScript guide](https://docs.reliantlabs.io/sdk/typescript.md) covers them, and the Go SDK does not wrap them. ## Related topics * [SDK overview](https://docs.reliantlabs.io/sdk/overview.md) * [Go SDK](https://docs.reliantlabs.io/sdk/go.md) * [TypeScript SDK](https://docs.reliantlabs.io/sdk/typescript.md) This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.