API and MCP

Authentication

Create a key in account settings and send it as a bearer token. The secret is shown once and cannot be retrieved afterwards. A key is a credential, not an entitlement: every call re-checks the subscription behind it, so a key outliving its plan stops working.

curl https://hashike.io/api/v1/opportunities?status=open&limit=5 \
  -H "Authorization: Bearer hsk_live_..."

Endpoints

How usage is counted

Requests are not the unit — records returned are. A source row exposed verbatim counts as one record. An analytical response that exposes no individual rows counts as one analysis instead, which makes the question-shaped calls the cheap ones. A derived response that does expose rows (research_brief with includeSampleAwards) is charged one analysis plus one record per row exposed.

"usage": { "records": 0, "analyses": 1 }   // an aggregate
"usage": { "records": 21, "analyses": 0 }  // a profile with 20 awards
"usage": { "records": 5, "analyses": 1 }   // a research brief with 5 sample awards

GET /api/v1/usage — current allowance. Never metered.

Limits

• Free: Monthly allowance: 200 records · 4 analyses per month. General rate limit: 5 requests per minute. Analytical rate limit: 1 analytical request per minute.
• Research: Monthly allowance: 1,000 records · 20 analyses per month. General rate limit: 20 requests per minute. Analytical rate limit: 4 analytical requests per minute.
• Intelligence: Monthly allowance: 4,000 records · 80 analyses per month. General rate limit: 60 requests per minute. Analytical rate limit: 12 analytical requests per minute.

Allowances are the total of the subscription rows in your organization, identified by email domain, that currently grant API access, and reset on the 1st (UTC). Additional API keys do not increase them. Accounts with no row that currently grants API access receive the Free allowance.

Unavailable is not empty

When no brief has been computed for a scope, the response is status: unavailable with a reason, never an empty object. An empty result reads as “there is no market here”, which is a different and usually false claim. The same applies to a location outside coverage or an unrecognised buyer code.

{
  "status": "unavailable",
  "reason": "no_precomputed_brief",
  "message": "No research brief has been computed for this scope...",
  "scope": { "naics": "336611" },
  "usage": { "records": 0, "analyses": 0 }
}

Response shape

Every tool publishes a JSON Schema for its own output (outputSchema). MCP's tools/list returns it alongside inputSchema, and tools/call returns the same payload two ways: the usual text block, and structuredContent, so a client does not have to parse JSON out of text. What result contains differs by tool; status, scope, provenance and usage have the same shape on every tool.

Errors

MCP

The same tools are served over the Model Context Protocol. Point your AI client at the endpoint below and Hashike's research sits alongside your own documents — you keep working in the tool you already use instead of in someone else's chat window. Limits and metering are shared with the API.

https://hashike.io/api/mcp

Transport : JSON-RPC 2.0 over POST
Auth      : Authorization: Bearer hsk_live_...
Methods   : initialize · tools/list · tools/call · ping

This endpoint supports OAuth, which is what the MCP specification prefers for a remote server. A client registers itself, sends you to a consent screen in your browser, and receives an access token scoped to your own account — there is no API key to paste, and access is tied to you rather than to a shared secret. API keys still work as bearer tokens, for clients that do not speak OAuth.

Tool results arrive as JSON with their provenance attached, and each carries your remaining allowance so an agent can pace itself. A result with status: "unavailable" is not an error — it means that scope has not been computed or is outside coverage.

Webhooks

Still in development. The endpoint-registration section will not appear in account settings until this is enabled. What follows is the specification for once it is.

Event types: opportunity.created / opportunity.updated / award.created

{
  "id": "opportunity:ABC123:9f2c...",   // dedupe identity — key your idempotency on this
  "eventId": 48213,
  "type": "opportunity.updated",
  "entityType": "opportunity",
  "entityId": "ABC123",
  "data": { "opportunityId": "ABC123", "title": "...", "responseDeadline": "2026-11-01" },
  "ts": "2026-09-20T04:31:00.000Z"
}

Delivery is at-least-once: the same event can arrive more than once. Build your handler to be idempotent, keyed on payload.id — the event's dedupe identity.

Retries

A failed delivery is retried with exponential backoff: 1m, 5m, 30m, 2h, 6h, 12h, 24h. After the final attempt a delivery is recorded as failed and is not retried again.

Verifying signatures

Every request carries X-Hashike-Signature and X-Hashike-Timestamp headers. The signing key is SHA-256 of the secret shown once at creation — not the secret string itself. Hash your secret, use that hash as an HMAC-SHA256 key over `<timestamp>.<raw body>`, and compare the result to the header in constant time. Reject the request if the timestamp is far from the current time (a replay).

const crypto = require("node:crypto");

function verify(secret, timestamp, rawBody, signatureHeader) {
  const signingKey = crypto.createHash("sha256").update(secret).digest("hex");
  const expected = crypto
    .createHmac("sha256", signingKey)
    .update(`${timestamp}.${rawBody}`)
    .digest("hex");

  const a = Buffer.from(expected, "utf8");
  const b = Buffer.from(signatureHeader, "utf8");
  const signatureOk = a.length === b.length && crypto.timingSafeEqual(a, b);

  const ageSeconds = Math.abs(Date.now() / 1000 - Number(timestamp));
  return signatureOk && ageSeconds <= 300; // reject anything older than 5 minutes
}