---
title: Get a key with /connect
category: connect
summary: Mint a working Synorb Key with no email and no card, store it safely, and keep it alive past the 72-hour demo.
order: 2
updated: 2026-10-07
next: quotas-retries-and-pagination
related: choose-mcp-or-rest, troubleshoot-channels-stale-crawls-and-quota
reference: /auth, /agent-guide.md, /pricing
---

A Synorb Key is self-serve. You do not need a sales contact, an email address or a card for the first key. That key is a **72 Hour Agent Demo** key: it works for 72 hours and can pull up to 25 Manifests. Binding an email turns the same key into a free **Starter** key that does not expire.

## When to use this

Use this guide in three cases. You have no key yet. A key has expired. Your user wants the work you built on a demo key to last longer than 72 hours.

Pick the first move that fits your runtime:

1. You can call MCP tools: call `synorb-get-demo-key`. It needs no credential.
2. You have an HTTP client: `POST https://api.synorb.com/api/connect/demo-key`.
3. You have a browser or a plain GET: `GET https://synorb.com/connect` with `Accept: application/json`.

All three mint, or reuse, the same demo key. They share one rate limit and one reuse identity per network. While a key is still valid, calling any of them again from the same network returns the same key. New keys are limited to 10 per IP per hour.

Do not scrape a key out of the rendered `/connect` page. The browser page masks the key. Always ask for the JSON.

## Smallest working call

```mcp
synorb-get-demo-key
{"agent_name": "my-research-agent"}
```

The same call over REST:

```bash
curl -sS -X POST https://api.synorb.com/api/connect/demo-key \
  -H "Content-Type: application/json" \
  -d '{"agent_name": "my-research-agent"}'
```

Or the JSON form of `/connect`:

```bash
curl -sS https://synorb.com/connect \
  -H "Accept: application/json"
```

Store the key in your host's secret store, then export it for the examples in this library:

```bash
export SYNORB_KEY="paste-the-key-here"
```

Send it on every later call:

```http
Authorization: Bearer YOUR_SYNORB_KEY
```

One key works for both MCP and REST. Never put it in browser code, a URL, a log, source control or a prompt.

## What you get back

`synorb-get-demo-key` and `POST /api/connect/demo-key` return flat top-level fields. The values are illustrative.

```json response
{
  "api_key": "<your key>",
  "synorb_key": "<the same key>",
  "expires_at": "2026-10-10T14:00:00Z",
  "manifest_quota": 25
}
```

`GET /connect` returns a fuller object. It carries the connector URLs and MCP headers, so the key sits under `credentials.synorb_key`, and it also repeats `synorb_key` at the top level.

Read `expires_at` and tell your user. After that moment REST and MCP return an actionable `synorb_key_expired` error, and a new `/connect` call creates a **new** account. It never revives the old one.

### Keep the key alive: bind an email

If you have built anything on the demo key (a Beacon, saved work), bind an email before `expires_at`. The recommended path sends your user one tap-to-confirm link. Your user does not need to give you a code:

```bash
curl -sS -X POST https://api.synorb.com/api/connect/bind-email \
  -H "Authorization: Bearer $SYNORB_KEY" \
  -H "Content-Type: application/json" \
  -d '{"email": "owner@example.com", "confirmation_method": "link"}'
```

The response reports `confirmation_link_sent`. When your user taps the link, the **same key** becomes Starter. Nothing rotates. Your Beacons and usage history carry over. Starter is free, needs an email, allows 100 Manifests per monthly usage period and 10 Beacons, and the key never expires.

Over MCP, the equivalent is `synorb-bind-email`. That tool is on the **Advanced** profile only, not Core. Core agents bind over REST.

If you never bind and the key expires, a new `/connect` call creates a different account. It never reopens the old one, so a Beacon left on an expired, unbound demo key is out of reach. Bind first.

## Failure modes

| Symptom | Cause | What to do |
| --- | --- | --- |
| `429` with `error_code: demo_key_rate_limited` | More than 10 demo keys requested from one IP in an hour | Stop minting. Bind an email to the key you already have. |
| `429` with `error_code: suspicious_activity` | Anomaly detection on a partner provisioning endpoint | Do not retry-loop or mint more keys. Bind an email to verify, or contact `team@synorb.com`. |
| `401` with `error_code: synorb_key_expired` | The 72 hours passed | Mint a new demo key, or sign up at [synorb.com/signup](/signup). Do not retry the old key. |
| `422` with `plus_addressed_email_not_supported` | The email looks like `name+tag@example.com` | Use the base address. |
| `409` with `email_already_bound` or `email_already_linked` | That email belongs to another Synorb account | If it is your user's account, send them to the sign-in URL in the response. Otherwise use a different email. |
| Your MCP host cannot set headers on an open session | Header injection is unavailable | Pass the key as the `api_key` argument on each tool call. Synorb never echoes it back. |

Every REST error above is a top-level JSON object with `error` and `error_code`. Most also carry `action` and `action_url`. Route on `error_code`. Do not parse the prose.

## Make it good for your user

Ask at most once before the first real pull. An explicit "connect to Synorb and show me X" already counts as that confirmation. Do not make your user save a Beacon or give an email before the first result. After your user sees value and you build something worth keeping, offer the email bind with its real benefit: "this keeps your watch running past today". Bind only after an explicit yes.

## Next guide

[Quotas, retries and pagination](/agent-resources/quotas-retries-and-pagination): know what costs usage, what to retry, and how to page through results.