Hiring Signals API

One POST, synchronous. Discovery, the roles and the delta all come back together.

curl -X POST https://hiring.ounie.com/api/scans \
  -H "Authorization: Bearer hrs_live_…" \
  -H "Content-Type: application/json" \
  -d '{"domain":"mercury.com"}'

• Your app key — Authorization: Bearer hrs_live_…, minted at /dashboard/api-keys. Five active keys per account.
• Your Ounie master key — an ounie_live_… key from ounie.com works across the whole Ounie app fleet, once you switch it on in your ounie.com API-key settings.
• The session cookie — the dashboard uses the same endpoints you do, signed in on .ounie.com.
• No auth at all — the x402 rail takes USDC on Base instead.

Hosts that cannot set an Authorization header (the Ounie AI Team’s manual MCP entry, for one) can pass ?api_key=hrs_live_… on any endpoint.

Costs 6 credits, or 6 + 1 per described role. Credits are reserved against the real role count, not a guess, and settled on what was produced.

{
  "ok": true,
  "scan": {
    "id": "…",
    "domain": "mercury.com",
    "company": "Mercury",
    "outcome": "found",
    "outcome_meaning": "We reached this company's live job board …",
    "headline": "Mercury has 55 open roles. 3 opened, 2 closed since Jul 28, 2026.",
    "platform": "greenhouse",
    "board_token": "mercury",
    "roles": [
      {
        "id": "8403127002",
        "title": "Staff Software Engineer, Payments",
        "team": "Engineering",
        "function": "engineering",
        "seniority": "staff",
        "location": "San Francisco, CA",
        "remote": null,
        "employmentType": null,
        "postedAt": "2026-07-14T09:04:24-05:00",
        "url": "https://job-boards.greenhouse.io/mercury/jobs/8403127002",
        "description": null,
        "salary": null
      }
    ],
    "summary": {
      "totalOpen": 55,
      "byFunction": { "engineering": 21, "sales": 9, "design": 4 },
      "bySeniority": { "senior": 14, "staff": 6, "unknown": 22 },
      "locations": [{ "location": "San Francisco, CA", "count": 18 }],
      "remote": { "yes": 0, "no": 0, "unknown": 55 },
      "toolsMentioned": [],
      "descriptionsIncluded": false
    },
    "delta": {
      "since": "2026-07-28T11:02:19.441Z",
      "previousTotal": 54,
      "netChange": 1,
      "opened": [{ "id": "…", "title": "Solutions Engineer", "function": "sales", "url": "…" }],
      "closed": [{ "id": "…", "title": "Support Lead", "function": "support", "url": "…" }],
      "newFunctions": ["data"],
      "closedFunctions": []
    },
    "discovery": [
      { "platform": "greenhouse", "token": "mercury", "method": "careers-page",
        "status": 200, "jobs": 55,
        "note": "selected — most open roles of the boards that answered" }
    ],
    "roles_detailed": 0,
    "credits_spent": 6
  }
}

You give us a domain; we have to work out which applicant-tracking system that company uses. Three steps, in order:

• Their own careers page. We fetch /careers, /jobs, /company/careers, /about/careers and a few more, and look for a board link in the markup. This alone resolves about half of companies.
• A guess from the domain. Most companies name their board after themselves — airtable.com is airtable on Greenhouse. This takes the hit rate to roughly four in five.
• Probe every candidate in parallel and keep the fullest board. Never the first one that answers. Airtable and Mercury both return 200 on Greenhouse and on Ashby; their Ashby boards are empty shells while the real roles sit on Greenhouse. A first-match design reports zero for both.

Every candidate we probed comes back in discovery[] with its status, its role count and why it did or did not win — so a surprising answer is auditable rather than mysterious.

The distinction is the whole product. A sales team acting on a fabricated zero is worse off than one with no data at all, so a non-answer is always labelled and never charged for.

Every successful scan writes a snapshot of that board. The next scan of the same company diffs against it and returns delta.

• The diff key is the platform’s own job id, so a retitled req is not mistaken for a new one, and two roles with the same title do not collapse into one.
• The first scan of a board has no delta. You get delta: null and a deltaNote saying so — not a row of zeros that would read as “nothing changed”.
• The snapshot corpus is per board, not per account. A job board is public, so every rail contributes to it and every rail benefits — including keyless x402 callers, who have no account to keep history against.
• We prefer a comparison snapshot at least an hour old, so two scans a minute apart do not return a meaningless empty delta. When the only earlier snapshot is more recent than that, we use it and since says so.

Three applicant-tracking systems that agree on almost nothing get normalized into one shape. Where a platform genuinely does not publish something, the field is null and the scan carries a capabilities block saying so — we never infer a value to make the shape look complete.

Functions: engineering, product, design, data, security, it, sales, marketing, customer_success, support, finance, legal, people, operations, research, executive, other. Seniorities: intern, junior, mid, senior, staff, principal, lead, manager, director, vp, executive, unknown.

Three ship. The property they all share is the one that matters: a board that does not exist returns a clean 404, which is what lets us tell “not on this platform” apart from “not hiring”.

And the ones deliberately absent, with the reason for each:

Free — you already paid for these.

GET https://hiring.ounie.com/api/scans?limit=20
GET https://hiring.ounie.com/api/scans?domain=mercury.com
GET https://hiring.ounie.com/api/scans/<scan_id>

Filtering by domain is how you pull a company’s whole scan history and watch the board move over time.

Endpoint  https://hiring.ounie.com/api/mcp   (legacy SSE: /api/sse)
Auth      Authorization: Bearer hrs_live_…
          …or https://hiring.ounie.com/api/mcp?api_key=hrs_live_…

Agents with no Ounie account pay in USDC on Base. Because the job boards cost us nothing to read, discovery runs before the quote.

curl -X POST https://hiring.ounie.com/api/x402/scan \
  -H "Content-Type: application/json" \
  -d '{"domain":"mercury.com"}'

# → 402
{ "x402Version": 1,
  "accepts": [{ "scheme": "exact", "network": "base",
                "maxAmountRequired": "72000",
                "asset": "0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913",
                "payTo": "0x…",
                "extra": { "name": "USD Coin", "version": "2" } }],
  "preview": { "company": "Mercury", "platform": "greenhouse",
               "open_roles": 55, "credits_equivalent": 6 } }

curl -X POST https://hiring.ounie.com/api/x402/scan \
  -H "X-Payment: <base64 signed payload>" \
  -d '{"domain":"mercury.com"}'

• A company with no reachable board is a 400, with no price in the body. You never sign an authorization for work that cannot be delivered. The response carries the full discovery[] trail and a hint to retry with a board token.
• The 402 quotes the exact final amount, descriptions included — not a ceiling. On this rail you cannot settle for less than you quoted (the exact scheme compares the signed value, so a reduced settlement is refused after the work is done), and quoting exactly removes the failure mode.
• Verify → run → settle. Your signature is checked off-chain first, the board is read, and only then does money move. Nothing is settled for a result we could not produce.
• The 402 also carries a free preview: the company, the platform and the open-role count, so you can decide whether the answer is worth $0.072 before signing anything.
• x402 scans still get a delta. The snapshot corpus is keyed by board, not by account, so a keyless caller both reads from it and contributes to it.

We self-throttle and cache board discovery per domain. None of the three platforms publishes a rate-limit header, so being courteous is on us rather than on them.