Skip to Content
InvyteDocs
Clients & delivery

Match a new role against Talent Hub

Find the people ready to go for an accepted new role with no Job yet: a strong fit on the job-description search, identity verified and agreed to be shared. They are recorded on the request as its shortlist, with the target and whether a Job is needed too (fewer than the target). Once per request: a matched request answers with its shortlist without searching again. The search counts against your daily search budget.

POST
/operations/requests.match

Authorization

bearer
headerAuthorizationBearer <API key or OAuth token>

An organization API key (ink_live_…, ADR-0124), or the OAuth access token a person's AI client gets from the Recruiter MCP sign-in. Only the Authorization header is accepted.

Header Parameters

Idempotency-Key?string

Makes a write safe to repeat: the same key and input return the first result. Required for agents' writes and for anything a person confirms.

Match^[A-Za-z0-9._:-]+$
Length8 <= length <= 128

Request Body

application/json
  1. body
input*
confirmation?string

The id from a confirm or awaiting_approval Outcome, sent with the same input and key to go ahead.

Response Body

Done. A replay of the same key and input omits output.

application/json
  1. response
status*unknown
output?
replay?
actionId*string
Example Request
curl -X POST 'https://www.invyte.ai/api/recruiter/v1/operations/requests.match' \  -H 'Content-Type: application/json' \  -d '{  "input": {    "requestId": "string"  }}'
Example Response
{  "status": "done",  "output": {    "id": "string",    "kind": "new_role",    "status": "new",    "trust": "unknown",    "channel": "email",    "threadId": "string",    "from": "string",    "text": "string",    "facts": {      "title": "string",      "location": "string",      "workplace": "onsite",      "compensation": "string",      "headcount": 1,      "startBy": "string",      "mustHaves": [        "string"      ],      "niceToHaves": [        "string"      ],      "company": "string",      "notes": "string"    },    "missing": [      "title"    ],    "client": {      "id": "string",      "name": "string"    },    "job": {      "id": "string",      "title": "string"    },    "assignee": {      "kind": "autopilot"    },    "outcome": "string",    "shortlist": {      "target": 1,      "needsJob": true,      "people": [        {          "key": "string",          "label": "string",          "fitNote": "string"        }      ],      "share": {        "shareId": "string",        "people": 0,        "sharedAt": "2019-08-24T14:15:22Z"      },      "told": true,      "picks": [        {          "key": "string",          "added": true        }      ]    },    "declinedReason": "string",    "createdAt": "2019-08-24T14:15:22Z",    "updatedAt": "2019-08-24T14:15:22Z"  },  "replay": {    "requestId": "string",    "status": "string"  },  "actionId": "string"}

List requests POST

What clients and anyone else asked for, newest first: the organization's, one Client's or one Job's, optionally by status, with how many there are in each status. A New, Clarifying or Ready request came from someone who isn't a Client yet and waits for a person to accept or decline it.

What a request still misses POST

The request with what is still unknown (`missing`), worked out from its facts: ask the sender only for these, never for anything else.