Clients, shares and delivery
For agencies: Clients, Candidate Shares, delivery and Client decisions.
Agencies hire for other companies. Invyte models those companies as Clients.
Clients
A Client has contacts (its hiring managers and viewers), an account owner on your team, and an agreement that decides
what it sees about candidates. Create and manage Clients with clients.create, clients.addContact and
clients.setAgreement. A Job belongs to a Client with jobs.setClient.
Client contacts never see your recruiting app. They see what you share with them.
Candidate Shares
A Candidate Share is a list of candidates shared with people outside your organization, such as a Client's hiring
manager. Recipients sign in with a one-time code; each one's access can be revoked or extended. Create one with
shares.create, preview it as its recipients see it with shares.preview, and manage recipients with
shares.inviteRecipient and shares.revokeRecipient.
Delivery
Delivery sends a Job's candidates to its hiring side and follows up until they decide:
- One live shortlist page per Job, where the hiring side decides on each candidate.
- Follow-ups at 24 and 72 hours, then a courtesy reminder, then an escalation to the account owner.
- Decisions made on the page, or replied by email or in Slack, are recorded (
client.decide).
Delivery works the same way for in-house Jobs: a Job with no Client is delivered to the members assigned to it, and with nobody assigned, to your admins.
Send candidates with delivery.deliver, see where a Job stands with delivery.status, and see what's due with
delivery.dueFollowUps.
Client requests
New roles often arrive by email. A request captures one: what's known, what's missing (requests.missing), then
accept it into a Job (requests.accept) or decline it.
Operations in this area
| Operation | What it does | Effect |
|---|---|---|
clients.createMCP clients_create | Add a Client Add a Client: a company you hire for, with its first hiring manager (who gets email from you; signing in is optional), its website and who runs it. Its email channel opens at once and its website is read into a company profile in the background. | WritePaid |
clients.renameMCP clients_rename | Rename a Client Change a Client's name. | Write |
clients.archiveMCP clients_archive | Archive a Client Archive a Client so new Jobs can't be put under it. Its Jobs and the roles held on it stay. | Write |
clients.setAccountOwnerMCP clients_setAccountOwner | Set a Client's account owner Choose the member who runs a Client: they manage its contacts, agreement and contact releases. null leaves it without one. | Write |
clients.addContactMCP clients_addContact | Add a client contact Add a person at the Client. They get the Client's email updates; signing in to the client workspace is optional. | Write |
clients.updateContactMCP clients_updateContact | Change a client contact Change a client contact's name or role. A Client keeps at least one hiring manager. | Write |
clients.removeContactMCP clients_removeContact | Remove a client contact Stop a client contact getting updates and signing in to the client workspace. A Client keeps at least one hiring manager; they can be added again later. | Write |
clients.setAgreementMCP clients_setAgreement | Set what a Client sees Choose the Client's agreement: a preset (balanced, delivered_only, full_pipeline) plus any fields that differ from it. It applies to everything the Client sees from now on, on every channel. | Write |
clients.releaseContactMCP clients_releaseContact | Release a candidate's contact details to a Client Let the Client see one candidate's email and phone, as an introduction, in the client workspace and share pages. Email and Slack never carry them. | Reaches people |
clients.refreshKnowledgeMCP clients_refreshKnowledge | Refresh a Client's company profile Read the Client's website again into its company profile (what they do, products, mission, stage, locations, tech, culture), optionally from a new website. It runs in the background. | WritePaid |
clients.listMCP clients_list | List Clients List the Clients (the customers a staffing organization hires for) whose Jobs you can see, by name, with how many of their Jobs you can see, their account owner, contacts and Slack status. Administrators see every Client. | Read |
clients.getMCP clients_get | Get a Client One Client's workspace: its contacts, its agreement (what it sees of candidates), its channels and its company profile. For anyone who sees one of its Jobs. | Read |
clients.knowledgeMCP clients_knowledge | Read a Client's company profile What the Client's website, and public pages about it, say: what they do, products, customers, mission, vision, goals, stage, locations, tech stack and culture; and, each with the page it came from and whether it was stated, reported or inferred, its industry, company type, funding stage and last round, founded year, headquarters, headcount band, remote policy, leadership, hiring facts and recent news. A fact left out is unknown. Use it to write Job descriptions and sourcing criteria. | Read |
shares.listMCP shares_list | List Candidate Shares The Candidate Shares you manage, newest first, or one Job's: who they went to, how many candidates, and when recipients last opened them. | Read |
shares.getMCP shares_get | View a Candidate Share One Candidate Share: the candidates on it and what is shared about them, each recipient's access and invitation, when they opened it, and their fit marks and introduction requests. | Read |
shares.createMCP shares_create | Share candidates Share up to 25 of a Job's candidates with people outside your organization as a named share list, as the share composer does. Each recipient gets an email invitation and signs in with a code; they see only the chosen sections (by default everything but contact details, with full interviews and assessment overviews), including newer results as they come, until the list is closed or its access ends. | Reaches people |
shares.inviteRecipientMCP shares_inviteRecipient | Invite someone to a share Give one more person access to an open Candidate Share of a Job: they get an email invitation and see what the share shows. | Reaches people |
shares.updateMCP shares_update | Edit a share list Change an open share list of a Job: its name, recipients (new addresses get an email invitation, removed ones lose access), when access ends, the note, whether viewers may add viewers, its candidates, and what each candidate shows. The link stays the same. Pass the list's `version` from shares.get: if anyone changed the list since, nothing changes and the call is refused. Only share lists can be edited; a fixed share can be reshared instead. | Reaches people |
shares.duplicateMCP shares_duplicate | Duplicate a share list Share the candidates of a Job's share list again as a new list, with the same visibility: by default named '<name> (copy)', with the same recipients (except revoked ones), note and expiry. Each recipient gets an email invitation. Pass the list's `version` from shares.get: a list changed since is refused. | Reaches people |
shares.reshareMCP shares_reshare | Reshare a fixed share Share a fixed (older, non-list) Candidate Share's candidates with new people: a new share showing what the original still can. Each recipient gets an email invitation. Share lists are duplicated instead. | Reaches people |
shares.closeMCP shares_close | Close a share Close a Candidate Share for good: nobody can open it again and pending access requests can no longer be approved. | Can't be undone |
shares.revokeRecipientMCP shares_revokeRecipient | Revoke someone's access to a share Take one recipient's access to a Candidate Share away now (the recipient ids are in shares.get). | Can't be undone |
shares.extendRecipientMCP shares_extendRecipient | Extend someone's access to a fixed share Move when one recipient's access to a fixed Candidate Share ends to a later date. A share list's access ends with the list: change it with shares.update. | Write |
shares.resendInvitationMCP shares_resendInvitation | Resend a share invitation Email one recipient their invitation to a Candidate Share again, with a fresh sign-in link. | Reaches people |
shares.accessRequestsMCP shares_accessRequests | List a share list's access requests The people who asked for access to a share list from its link, newest first: their address, their note, and whether the request is pending, approved or denied. | Read |
shares.decideAccessRequestMCP shares_decideAccessRequest | Approve or deny an access request Decide a pending request for access to a share list. Approving emails them an invitation to the list; denying tells them on the request page that it was declined. | Reaches people |
shares.undoAccessDecisionMCP shares_undoAccessDecision | Undo an access request decision Undo the decision on an access request: an approval takes the access it gave away again; a denial puts the request back to pending. | Can't be undone |
shares.previewMCP shares_preview | Preview a share as its recipients see it What recipients of a Candidate Share see right now, per candidate: the name (unless hidden), the sections they see masked, the evaluation, each interview and assessment round at its level, and whether the resume file and hiring team notes are shared. Recordings and files open only in the app. | Read |
shares.createFromTalentHubMCP shares_createFromTalentHub | Share a Talent Hub shortlist Share up to 25 people from your Talent Hub, without a Job, as a live list. Each recipient gets an email invitation and signs in with a code. Contact details are never shared; each person may carry a 'why they match' line. People who haven't agreed to be shared or aren't verified are flagged in the review. Name the request it answers (`requestId`) to send a request's Talent Hub shortlist. | Reaches people |
delivery.deliverMCP delivery_deliver | Send candidates to a Client Send a Job's candidates to its Client: one email from your agent to the Client's contacts, copying your team on the Job, and a Slack card when the Client's channel is connected. On a Job with no Client, its hiring team (everyone assigned to the Job, or the admins when nobody is) gets the same shortlist and email. Each candidate hears their profile was shared. If the hiring side already heard about this Job in the last day, the candidates go with the next follow-up as "N more added". | Reaches people |
delivery.statusMCP delivery_status | Delivery status for a Job What was sent to the Job's Client and when, each candidate's current decision with the Client's reason, their response clock, and the next follow-up due on them. | Read |
delivery.dueFollowUpsMCP delivery_dueFollowUps | Follow-ups due with Clients The follow-ups due now on candidates waiting on Clients, one per Job and kind, in order. Computed from when each candidate was sent, so a missed check loses nothing. | Read |
delivery.followUpMCP delivery_followUp | Send a follow-up to a Client Send one due follow-up for a Job (from `delivery.dueFollowUps`): a reminder, digest, 72h notice or courtesy-day note to the Client, or the escalation to the Client's account owner (also due at once when every channel refused a delivery). Refused when it is not due. | Reaches people |
delivery.responseTimesMCP delivery_responseTimes | Client response times Per Client: candidates waiting and the oldest, how many were decided, median and average hours to a decision, and escalations. Over the Jobs you can see. | Read |
client.decideMCP client_decide | Record a Client's decision on a candidate Record that the Client approved or passed on a candidate they were sent, as they told you by email, Slack or on a call. It stops the candidate's response clock and never moves the candidate; the Client gets a short note confirming it, with how to change or undo it. A later decision replaces it. | Reaches people |
client.undoDecisionMCP client_undoDecision | Undo a Client's decision on a candidate Take back the Client's current decision on a candidate, as they asked. Name the decision (`decisionId` from `delivery.status`) so a newer one is never undone. The candidate waits on the Client again and the Client gets a short note confirming it. | Reaches people |
client.requestMCP client_request | Record a Client's request Record what a Client asked for: more candidates, a requirement change, a pause or a new role. The intake agent drafts the change, the account owner approves it and the Client confirms it; a Client never edits a Job. | Write |
client.requestsMCP client_requests | Read a Client's requests What a Client asked for, in their words: one request by id (the `requestId` a `client.requested` signal carries), or the latest 20, newest first, optionally about one Job. | Read |
requests.addressMCP requests_address | Your requests address The organization's open address: anyone may email a hiring need there (an agency can forward its own jobs@ address to it), and it becomes a request waiting to be accepted. Null while inbound email isn't set up. | Read |
requests.listMCP requests_list | List requests 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. | Read |
requests.getMCP requests_get | Read a request One request by id, or the open request on a conversation thread (an unknown sender's): its words, the facts given so far, what is still missing and where it stands. | Read |
requests.missingMCP requests_missing | What a request still misses The request with what is still unknown (`missing`), worked out from its facts: ask the sender only for these, never for anything else. | Read |
requests.submitMCP requests_submit | Record a request Record what someone asked for: a new role, a change to a live Job (name the Job), more candidates, a pause. A person's own request is trusted and accepted at once. An agent relaying a message names the thread it came on, and trust comes from who wrote it: a Client's contact is accepted at once, someone unknown waits for a person to accept it, and nothing is created or spent before then. | Write |
requests.amendMCP requests_amend | Add what a sender told us to their request Add the facts the sender gave since (title, location, compensation, start date, must-haves, company). A New or Clarifying request with nothing missing becomes Ready for a person to accept. Facts are their words, never guesses. | Write |
requests.acceptMCP requests_accept | Accept a request Take on a request from someone who isn't a Client yet: into one of your Clients, or a new Client named here (its first hiring manager is the sender). Autopilot's Intake works it, or you do (`assignTo: me`). Any member may accept. | Write |
requests.declineMCP requests_decline | Decline a request Turn a request down, with the reason your team sees. Nothing is created and the sender isn't told by this. | Write |
requests.matchMCP requests_match | 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. | Write |
requests.noteShortlistMCP requests_noteShortlist | Note progress on a request's shortlist Record that the client was told about the request's shortlist (`told`), or that someone the client picked on it was asked to be added to the request's Job (`added`, their key). A request with nothing else owed is then done. | Write |
requests.resolveMCP requests_resolve | Mark a request done The request is done: name the Job it made or changed and say in one line what was done. A request with a Talent Hub shortlist still to share keeps the Job and is done once the shortlist goes. | Write |