Skip to main content

Start here

This section is for partners with a key. Everything below needs a partner API key. If you just want to point your own AI assistant at Signo, you do not need one: see For AI assistants.

Signo gives your users AI agents that live on your pages. On a market, vault, position or wallet page, a user turns an agent on in one or two clicks; it watches the position, notifies them on Telegram, and prepares the next transaction for them to review and sign. Underneath, a plain-English request becomes a ready-to-sign, multi-step, cross-chain plan. You build the front end; Signo is the back end. Every endpoint returns unsigned transactions and the user's own wallet signs, so nothing is custodial.

This page is the whole integration at a glance. The API page has the rules that make it feel right, the Agents page covers what agents can watch, and the API Reference has every field.

What you can offer your users​

Agents in one or two clicks. Your page already knows the market, vault or position the user is looking at. Signo's catalog gives you the agents that fit it (a maturity reminder, a fixed-rate entry, a health check, and so on), each with its copy and fields. You render the card; on submit, Signo saves the agent. When the user's wallet is already linked to Telegram that is one click and done. When it is not, Signo hands back a short-lived link that connects Telegram and saves the agent in the same step. From then on the agent watches, notifies, and can prepare an outcome the user opens for review and signing. Three calls: GET /agent-catalog, POST /surfaces/resolve, POST /surfaces/activate; details under Agents in one or two clicks.

A chat that ends in a signed transaction. For free-form asks, a chat card: the user types an outcome ("move my idle USDC into the best stable yield"), watches the reasoning stream in, answers a clarification if one comes back, sees the plan with a per-step simulation, then signs each step from their wallet. Build that, not a console: no raw JSON, no sidebars, no manual "Review plan" button. The UI guidelines on the API page spell it out.

Three ways in​

  1. Hand it to a coding agent. Copy the Agent Integration Prompt, paste it into Claude Code, Cursor or any coding agent, and it builds the chat box against the API, signing and simulation included. This is the fastest path and where most partners start.
  2. Use the SDK. @signo-fi/sdk runs on your server and holds the key; @signo-fi/sdk-web renders the chat and in-page agents in the browser. Delivered as tarballs today, npm publish pending.
  3. Call the API directly, or mount the MCP server. The endpoints are plain JSON over HTTPS (API Reference); the hosted MCP server exposes the same engine as tools for Claude Code, Cursor and other MCP hosts.

Get a key​

API keys are issued only through the Signo Partner Portal: sign in with your partner organization, open API Keys, and generate the key. It is shown once, so store it where your backend reads secrets; the portal keeps only a hash. Rotate and revoke from the same page — a rotation issues the new key and stops the old one at the same moment. During beta each partner gets one key; email the Signo integration team at contact@signo.fi if you need more, or to get portal access in the first place.

The key looks like sg_beta_..., goes in Authorization: Bearer, and stays on your server, never in a browser bundle. Each delivered call costs 5 credits; GET /usage shows the balance and GET /meta lists the actions and chains your key can use.

The four calls​

Base URL https://app.signo.fi/api/v1beta. Wallets are { address, chain }, with the chain the user will act on: ethereum, base, arbitrum, optimism, polygon, xlayer, robinhood or solana.

1. Intent. Natural language in, structured intents[] out, or clarifications[] when the ask is ambiguous. Send Accept: text/event-stream to stream the reasoning; plain JSON is fine for a first try.

curl https://app.signo.fi/api/v1beta/intent \
  -H "Authorization: Bearer $SIGNO_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "prompt": "swap 100 USDC to ETH on Base",
    "wallets": [{ "address": "0xYourUserWallet", "chain": "base" }]
  }'

The response carries reasoning (prose written for the user), kind (transactional or informational) and either intents[] or clarifications[]. Show the reasoning in the chat; when clarifications come back, render them as choices and send the pick as the next prompt.

2. Plan. When intents[] is non-empty, call /plan at once, with no "Review plan" click in between. Pass the same wallets, with real balances when you have them, because steps are sized from balances.

curl https://app.signo.fi/api/v1beta/plan \
  -H "Authorization: Bearer $SIGNO_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "intents": <intents from step 1>, "wallets": [{ "address": "0xYourUserWallet", "chain": "base" }] }'

Returns unsigned steps[] with real calldata, in signing order, plus a summary.

3. Simulate. Dry-run each chain's steps against a fork before any wallet opens, one call per chain, and show the per-step result in the chat card.

curl https://app.signo.fi/api/v1beta/simulate \
  -H "Authorization: Bearer $SIGNO_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "chain": "base", "sender": "0xYourUserWallet", "steps": <that chain's steps> }'

4. Re-encode, then sign. Quotes are perishable. Right before the wallet opens, re-encode the one step being signed and hand the fresh calldata to the wallet. actual_amount is a decimal in token units (step.amount, or the chained estimate for a chained step), not wei. If re-encode fails, stop and show its reason; never sign plan-time calldata.

curl https://app.signo.fi/api/v1beta/steps/reencode \
  -H "Authorization: Bearer $SIGNO_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "step": <the step being signed>, "actual_amount": <step.amount> }'

A plan-only integration (Tier A) stops after step 3 and proves the engine without a signer. Adding a signer (Tier B) means following the signing rules on the API page.

Agents in one or two clicks​

Server-side, with a key that has the agents scope:

  1. GET /agent-catalog lists your tenant's agent definitions: the subject each one needs (market, vault, position, asset or wallet), its copy, fields, actions, and whether it notifies, prepares, or both.
  2. POST /surfaces/resolve with the user's wallet and the page's subject. The response is safe to send to the browser: it carries the Telegram link state and any agent already attached to that wallet and subject, so a returning user sees their own settings.
  3. Render it. On an explicit submit, send the chosen field values and action from your backend to POST /surfaces/activate.
  4. Read outcome. activated means the wallet was already linked and the agent is saved: show it, there is nothing to open. requires_action means the user opens the returned activation_url as is; it connects Telegram and saves the agent. Repeat submits are safe: the same configuration is a no-op, a changed one updates the same agent.

To show a prepared outcome, ask for it on resolve (include: ["result"]); when a review is available, POST /surfaces/review returns a short-lived review_url that opens the signing flow. The API page and the API Reference have the exact shapes.

What is live​

  • The /v1beta API: intent, plan, simulate, steps/reencode, positions, usage, meta.
  • Agents and webhooks: plain-English or typed agents that watch prices, yields, health and portfolios, with signed webhook delivery and an events rail.
  • The hosted MCP server, same key, same metering.
  • The in-page agent API for partner surfaces: catalog, surfaces, Telegram link status.
  • The SDK packages, delivered as tarballs; the npm publish is pending.

Next​

  • API: UI guidelines, signing rules, simulation, multi-turn conversations, clarifications, errors.
  • API Reference: every endpoint and field.
  • SDK: the server client and the browser kit.
  • Security: the trust model.
  • Machine-readable: llms.txt for coding agents, and the OpenAPI spec.