The queue is the product. This puts it where you already work.

Every request carries the key as a bearer token. Keys look like hf_live_ followed by 32 characters. A key in a query string is not accepted; it would end up in logs.

curl https://hellofew.com/api/v1/queue \
  -H "Authorization: Bearer hf_live_…"

Errors are JSON with a status: { "error": "invalid_key", "message": "…" }. A missing or revoked key is 401, an unknown lead is 404, a lead that has already moved on is 409, a bad body is 400.

The same seven operations as tools, over the MCP Streamable HTTP transport, at https://hellofew.com/api/mcp, with the same bearer key. The tools are get_queue, approve_lead, skip_lead, get_replies, get_icp, update_icp and get_stats. Their descriptions tell the model what the product is and that approving sends a real invitation from your account under the published limits, so a model that has never heard of Hellofew still knows which tool is the irreversible one.

Cursor, Claude Code, and clients that take a URL

{
  "mcpServers": {
    "hellofew": {
      "url": "https://hellofew.com/api/mcp",
      "headers": {
        "Authorization": "Bearer hf_live_…"
      }
    }
  }
}

Claude Code: claude mcp add --transport http hellofew https://hellofew.com/api/mcp --header "Authorization: Bearer hf_live_…"

Claude Desktop (via mcp-remote)

{
  "mcpServers": {
    "hellofew": {
      "command": "npx",
      "args": [
        "-y",
        "mcp-remote",
        "https://hellofew.com/api/mcp",
        "--header",
        "Authorization: Bearer hf_live_…"
      ]
    }
  }
}

Stateless: every call authenticates on its own, there is no session to resume, and GET returns 405. A client that only speaks the older SSE transport is not supported.

Set a URL on /integrations and each reply is POSTed there as JSON shortly after it lands on LinkedIn. The inbox stays the source of truth: if your endpoint was down, GET /replies?unread=1 has everything the webhook would have told you.

POST https://example.com/hooks/hellofew
Content-Type: application/json
x-hellofew-signature: sha256=3f8a…

{
  "event": "reply.received",
  "at": "2026-10-14T08:12:04.000Z",
  "workspaceId": "7b62d6e5-…",
  "lead": {
    "id": "0f3c…",
    "name": "Priya Nair",
    "headline": "Head of Sales, Clinic Software",
    "profileUrl": "https://www.linkedin.com/in/…"
  },
  "message": {
    "id": "a91e…",
    "text": "Sure, send it over",
    "intent": "interested",
    "receivedAt": "2026-10-14T08:12:00.000Z"
  }
}

The signature is HMAC-SHA256 of the raw request body under the secret shown once when you set the URL, hex-encoded, in x-hellofew-signature as sha256=<hex>. Anyone can POST to a URL, so compare it before you trust the body — with a constant-time comparison, against the bytes you received, not a re-serialised copy.

import { createHmac, timingSafeEqual } from "node:crypto";

export function verify(rawBody: string, header: string, secret: string): boolean {
  const expected = "sha256=" + createHmac("sha256", secret).update(rawBody).digest("hex");
  return header.length === expected.length && timingSafeEqual(Buffer.from(header), Buffer.from(expected));
}

Every write goes through the same caps as the UI. The API does not have its own numbers; it has the product's, which are constants in the source so that neither you nor we can raise them in a hurry.

• 20 invitations a day, 80 a week (50 a week on a free LinkedIn account, which cannot send notes). Approving a hundred leads through the API queues a hundred approvals; it sends 20, and the rest wait.
• A warm-up ramp. A connected account starts at 5 a day and reaches the ceiling on day 21, because the pattern LinkedIn most reliably restricts is a quiet account that suddenly is not. Reconnecting after a restriction restarts the ramp.
• An accept-rate breaker. LinkedIn watches how many of your invitations are ignored and restricts accounts where the answer is most. We watch the same number and stop first: below 15% the daily cap halves, below 8% sending stops, and a blunter check runs from day four because a proper accept rate needs invitations a week old. GET /stats shows dayCap after the breaker.
• Working hours only, in the account's own timezone, and never on a weekend or a public holiday there. windowOpen and nextSendAt say when.
• Under 150 connections, nothing is sent at all. A near-empty profile sending invitations is the other pattern LinkedIn restricts. The account is held, and sending.detail says so.
• 12 follow-on messages a day, to people who accepted, and 25 new people found a day, which is why a queue is rarely longer than that.
• 600 API requests per key per hour, answered 429 with a retry-after beyond it. Counted per server process, not shared, so the true ceiling is a small multiple of that; it exists to catch a loop, not to meter you.

None of this makes a LinkedIn account impossible to restrict. LinkedIn's terms prohibit automation and their detection keys on things nobody outside LinkedIn controls. The honest claim is that these limits sit three to five times under what the category calls safe, and that they are published here so you can check them against what the API does.