Skip to main content
Available today: the MCP server and the public Career Page surface. Upcoming: partner API credentials and the partner GraphQL API described below. See Authentication.

​
Purpose

This page is the one-screen orientation for developers: what you can connect today, how the partner API is shaped, and how a typical integration flow works end to end. The full operation-by-operation technical reference is Upcoming, together with partner authentication.

​
Available today: the MCP server

Connect Claude, ChatGPT, Microsoft 365 Copilot or another MCP client to Exterview.
  • More than 45 tools. Read and write tools across jobs, candidates, interviews, panels, reports and billing status. Upcoming: run_the_role (starting a role run), resolve_gate (answering an Agent Inbox item) and sending code assessment invites.
  • OAuth 2.1 with Microsoft sign-in. Each client gets its own scopes, and every call runs as the signed-in person, inside your organization.
  • Safe writes. Every write tool needs your confirmation, and adverse actions show a preview first. There are no delete tools.
See Microsoft & Interoperability.

​
Upcoming: the partner API

​
How the partner API is shaped

  • GraphQL-first, one endpoint. A single endpoint serves every intelligence capability: create the entities, trigger an evaluation, then read the result. A small REST surface exists only for a health check and typed bulk-file ingest (candidate and job uploads). everything else is GraphQL.
  • Scoped to your organization. Every request runs inside your organization. Your organization and role are derived from your credentials on the server, never trusted from the request body. There is no access to another customer’s data.
  • Poll-based, no outbound webhooks. Exterview does not send outbound webhooks to partner integrations today. Long-running operations, like an AI phone screen, are read by polling the relevant record until its status is ready, rather than waiting for a push notification.
  • Filtered and paginated reads. List operations accept arguments to narrow results (by status, by parent entity, by search term) and are paginated rather than returned in one call.

​
A typical integration flow

Regardless of which evaluation you’re driving, the shape is the same:
1

Create or locate the entities

A job and a candidate must exist first, created individually or in bulk.
2

Trigger the evaluation

Call the capability’s trigger operation. This starts async work; it doesn’t return the finished result.
3

Poll for completion

There’s no outbound webhook. Poll the record until its status reaches a terminal state.
4

Read the AI output

Once ready, read the report: the structured, cited evaluation.
5

Read the stack rank

See where the candidate now sits, rolled up across every completed round for the job.
See the narrative version of each capability (what it does and why you’d use it) under Capabilities and Supporting.

​
Partner authentication

Partner access will use API-key or OAuth client-credentials with scopes (read, write, and higher-sensitivity scopes for actions that spend money, message candidates, or change a hiring decision). This is Upcoming. See Authentication for the full scope model.

​
Conventions

  • Errors follow the standard GraphQL { data, errors } shape; a custom error-code taxonomy isn’t published yet.
  • Rate limits and idempotency for the partner API are Upcoming: per-key limits, quota headers, and required idempotency keys on money- or comms-impacting mutations.
  • Pagination will use Relay-style (edges/pageInfo) for GraphQL connections and REST-style (perPage/pageNumber) for a few endpoints like the stack-rank read.

​
FAQs

Through the MCP server, yes. The partner GraphQL API requires partner authentication, which is Upcoming; the public Career Page surface is open. See Authentication.
GraphQL-first. REST exists only for a health check and typed bulk-file ingest. See Bulk Ingest.
Every request is scoped to your organization, derived from your credentials on the server. There is no access to another customer’s data.
Not today. Long-running operations are read by polling the relevant record until it’s ready.
It publishes here once partner authentication is available. Publishing exact operation names ahead of access controls being in place is an exposure we avoid by design.
  • Authentication. The scope model and the prerequisite that gates the API.
  • Bulk Ingest. The REST routes for loading candidates and jobs in bulk.
  • Jobs & Candidates. The base entities every evaluation runs on.
  • Capabilities. What each capability does and why you’d use it.