Tether
DocsGitHub

Quickstart · door two

Use Tether AI

You have a product, data and a brand. You have never written a prompt and do not intend to. Tether brings the model, the billing and the surface — five steps, each one useful on its own.

Preview  →  Connect  →  Add actions  →  Govern  →  Embed

Nothing is live on your site until step five. Steps one to four happen on a test page.


Step 1 — Preview

Give Tether your website address and, if you publish one, your product feed.

curl -X POST $TETHER_URL/v1/preview \
  -H "X-Api-Key: $TETHER_SECRET_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "siteUrl": "yourshop.com", "feedUrl": "https://yourshop.com/feed.xml" }'

Tether reads your public pages — bounded, and obeying your robots.txt — and within minutes an assistant answers from them, in the shopper's language and your brand colours.

You have something to look at before doing any integration work. See Preview Mode.


Step 2 — Connect

Connect the systems that hold the truth. The universal path is your own API:

tether import openapi.json --api https://api.yourshop.com

The first run is refused and writes tether.declarations.json. Mark which operations only read and which write, then run it again with --declare and register the catalog it writes. Tether will not call anything you have not marked. The steps, and the HTTP form, are in Bring your AI, path B.

No OpenAPI document? In the onboarding console, choose Pick your project folder: your API's code is scanned in your browser, and only the drafted contract, which you see first, is sent. See the same scan in the console.

Live questions — stock in a location, an order's status, delivery tracking — are now answered from your API, and the preview label disappears from those answers. Your public content stays as background knowledge, still labelled.


Step 3 — Add actions

Marking a tool is_write is what turns an answer into an action. Give each one a risk level:

[
  { "name": "cancel_order",   "is_write": true, "risk": "elevated" },
  { "name": "change_address", "is_write": true, "risk": "elevated" },
  { "name": "refund_order",   "is_write": true, "risk": "high" }
]

A write can now be staged. It cannot yet be approved by anyone but your own API user, which is what step four is for. See Choosing risk levels.


Step 4 — Govern

Invite the people who may say yes. They get a magic link to your approval inbox — no password is held.

curl -X PUT $TETHER_URL/v1/users \
  -H "X-Api-Key: $TETHER_SECRET_KEY" \
  -H "Content-Type: application/json" \
  -d '[
    { "userId": 41, "role": "finance", "email": "finance@yourshop.com" },
    { "userId": 42, "role": "support", "email": "support@yourshop.com" }
  ]'

Then say who may approve what:

curl -X PUT $TETHER_URL/v1/policy \
  -H "X-Api-Key: $TETHER_SECRET_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "rules": [
    { "tool": "refund_order", "risk": "*", "roles": ["finance"], "approvers": 1 },
    { "tool": "*",            "risk": "elevated", "roles": ["support", "finance"] }
  ] }'

This step is why the inbox exists. On this door the person asking and the person approving are different people from the very first write — a shopper asks for a refund, someone in support or finance approves it. A support agent opening a refund sees the Approve button disabled with the reason: it is waiting for finance.


Step 5 — Embed

One script tag, and the same assistant you have been using on the test page is on your site:

<script src="/tether-assistant.js"></script>

<tether-assistant
  mode="floating"
  endpoint="https://api.trytether.ge"
  publishable-key="tpk_…"
  greeting="Hi, what would you like to find today?"></tether-assistant>

mode="floating" puts a launcher in the bottom-right corner of every page that opens the assistant as a panel. Leave it out only to draw the assistant inside a page, in a full-width container 620px tall. The publishable tpk_ key is scoped by the server to chat, streaming and rating an answer, and nothing else, so it is safe in a page. A staged write appears with its preview and no approve control — the visitor is not authenticated to your tenant, so there is no identity to attribute an approval to. See The widget.


Where each step leaves you

AfterYou haveLive on your site
PreviewAn assistant answering from your public content, labelledno
ConnectLive answers from your own systemsno
Add actionsWrites that stage instead of happeningno
GovernThe people who may approve, and what they may approveno
EmbedThe assistant in your brand, on your siteyes