reliant command’s workflow supervision and trigger reads are built on the Go SDK. The SDKs are those clients, packaged so your code can use them: a backend that starts a run when a customer signs up, a CI job that waits for a run’s verdict, a service that fires an automation, a web frontend that shows a live chat. From code you can start a run, watch it to a verdict, steer it, answer its questions and cancel it.
There are two SDKs, and they are for different places.
The API reference lists every remote procedure the Go SDK’s generated clients expose, and says which Go method wraps each one.
What the SDKs will not do
A run executes as a person, on that person’s machines, with that person’s connections and billing. So anything that decides who a run executes as, where, or whether an automation runs at all is not part of the public API: enabling, disabling, creating or editing a trigger, rotating a webhook token, approving or denying an approval, and minting tokens. The same goes for everything that exists to wire up a machine to Reliant. An SDK cannot do these things, and neither can any client you generate from the public definitions, because the procedures are not in them. You can still see an approval.Gates.Pending and Approvals.List in the Go SDK report one, so a supervisor process can tell a person that a run is waiting for them, but the decision stays with a person in the app, as Who can decide an approval explains. Enabling a trigger is a decision of the same kind; Automations covers it.
Credentials
The Go SDK authenticates with an API token: anrlat_… token that acts as the user who created it. Create one on a computer with a browser:
reliant:api permission (see Scopes for narrower ones) and lasts 90 days. Running the command again with the same --name replaces the token, which is how you rotate one, and reliant auth token revoke billing-service withdraws it. Sign in and tokens compares this with the credential the CLI itself uses, and Scripting and CI shows the same token in a pipeline.
Store the token as a secret in whatever runs your code, and pass it in RELIANT_TOKEN. The SDK reads that variable, and RELIANT_SERVER_URL if you run your own server, exactly as the reliant command does, so a script that works with the CLI works with the SDK. Because the token acts as you, the runs your code starts are yours: they appear in your run list, use your connections, and are billed to your account.
Two other credentials are not for the SDK. Your CLI login would be accepted, since it also carries reliant:api, but it adds deploy, secret and domain permissions that a service has no use for and should not hold. Daemon credentials belong to a machine and are refused by the API.
A webhook trigger has its own, narrower credential: the token or signing secret shown when the automation was enabled. It can do one thing, deliver an event to that one trigger, and the Go SDK’s NewWebhook uses it without any API token at all. If all your code needs is “start this automation”, that is the right credential to give it. See Webhooks.
Scopes
An API token made withreliant auth token create carries the single permission reliant:api, which is the whole of your API. Reliant also accepts narrower tokens, and enforces them on every call. A token with only runs:start can start runs and nothing else: it cannot cancel one, read the inbox or touch a trigger. reliant:api still permits everything below, so tokens you already have behave as before.
triggers:fire and triggers:manage imply nothing else. Firing a trigger now and changing what runs unattended are different authorities, and neither lets a token start or control a run directly. triggers:manage is the permission the server requires for the activation procedures. Neither SDK exposes those procedures, and the generated clients do not contain them, so no SDK call needs it today.
Everything else needs reliant:api. A narrow token that reaches any other procedure is refused with PermissionDenied and the reason scope_missing, which the Go SDK returns as ErrPermissionDenied. That list includes what you might expect a “read” token to do:
So a narrow token suits a service that starts runs and checks on them with
Runs.Get, or one that cancels runs, but not one that follows a run to a verdict: Follow reads a session’s updates, which only reliant:api may. Triggers.Fire looks the trigger up before firing it, so with a token that holds only triggers:fire, call the generated client’s FireTrigger with the trigger’s id instead; Beyond the wrappers shows how to build one. A token for a webhook-only caller needs no scope at all, because it does not use an API token: see below.
reliant auth token create cannot request a narrow scope yet. The login it runs through does not grant the runs and triggers scopes by name, so every token it makes is reliant:api. The flag will come back together with that change. Until then, a narrow token can only be minted through the control plane’s token API (CreateMyToken), and this page will name the CLI flag when it exists.Keep tokens out of frontends
An API token is long-lived and powerful. Never put one in code that ships to a browser, a mobile app or a desktop app: anyone who opens the developer tools has it. Use the Go SDK on your server, where the token is a secret, and give the frontend only what it needs to display. The TypeScript SDK takes whatever credential the signed-in user’s session holds through a small interface you implement, and it never asks for an API token. See the TypeScript guide.Versioning
Both SDKs follow Reliant’s API, not the app. The API isreliant.v1 and changes only additively within it: new procedures, new fields and new filters appear, and nothing you call is removed or changes meaning. A change that cannot be additive would be a reliant.v2, introduced beside v1 rather than in place of it. The public procedures are generated from the same definitions as the server, so a client cannot disagree with the server it was built from.
The Go module has no tagged releases yet, so you require it at a commit of main, and Go records that commit as a pseudo-version:
@main resolves to whatever is newest when you run it. To make a build reproducible, name a commit instead (@6bd6513537ed), or keep the version go.mod recorded and update it deliberately with another go get. Do not add a replace directive for the SDK: a module that depends on yours ignores it, and go install refuses a module that has one. The module needs Go 1.27 or newer. Once releases are tagged, this page will name the tag.
The TypeScript package is @reliantlabs/sdk, imported from its /client entry point. It is built from sdk/ts in the Reliant repository, at a version that follows the API (0.1.0 today). It is not on the npm registry yet: Reliant’s release train will publish it, and until then you build it from the repository, as the TypeScript guide describes. React hooks are not part of it yet.
Some calls are marked beta in the Go SDK: Pause, Resume and Interrupt, with their WithResult forms. They work, but their semantics around positions and interrupted tools are still settling, and they may change in ways the stable calls will not.
License
Both SDKs are licensed under the Apache License 2.0, so you can embed them in your own software, commercial or not. The rest of the Reliant repository is under the Business Source License; thesdk/ directory is the exception. The license FAQ has the details.