> ## Documentation Index
> Fetch the complete documentation index at: https://docs.exterview.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Developer Preview

> How the Exterview API will work: GraphQL-first, scoped to your organization, poll-based with no outbound webhooks, and not yet generally available.

<Warning>
  **Not generally available yet.** The API is documented ahead of launch so you
  can plan an integration. Partner authentication ships first — see
  [Authentication](/get-started/authentication) for the full scope model and
  status. Until then, nothing here is callable except the public Career Page
  surface.
</Warning>

## Purpose

This page is the one-screen orientation for developers: how the API is shaped, how it's scoped to your organization, and how a typical integration flow works end to end. Everything on this page describes what's planned, not what's live — the full operation-by-operation technical reference publishes once partner authentication ships.

## How the 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:

<Steps>
  <Step title="Create or locate the entities">
    A job and a candidate must exist first — created individually or in bulk.
  </Step>

  <Step title="Trigger the evaluation">
    Call the capability's trigger operation. This starts async work; it doesn't
    return the finished result.
  </Step>

  <Step title="Poll for completion">
    There's no outbound webhook. Poll the record until its status reaches a
    terminal state.
  </Step>

  <Step title="Read the AI output">
    Once ready, read the report — the structured, cited evaluation.
  </Step>

  <Step title="Read the stack rank">
    See where the candidate now sits, rolled up across every completed round for
    the job.
  </Step>
</Steps>

See the narrative version of each capability — what it does and why you'd use it — under [Capabilities](/capabilities/career-page) and [Supporting](/supporting/jobs-candidates).

## Authentication

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 a prerequisite that hasn't shipped yet. See [Authentication](/get-started/authentication) for the full scope model and current status.

## Conventions

* **Errors** follow the standard GraphQL `{ data, errors }` shape; a custom error-code taxonomy isn't published yet.
* **Rate limits and idempotency** are planned — per-key limits, quota headers, and required idempotency keys on money- or comms-impacting mutations — but not enforced yet.
* **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

<AccordionGroup>
  <Accordion title="Can I call the API today?">
    Only the public Career Page surface. Everything else requires partner authentication, which has not shipped. See [Authentication](/get-started/authentication).
  </Accordion>

  <Accordion title="Is it REST or GraphQL?">
    GraphQL-first. REST exists only for a health check and typed bulk-file ingest
    — see [Bulk Ingest](/supporting/bulk-ingest).
  </Accordion>

  <Accordion title="How is my data isolated from other customers?">
    Every request is scoped to your organization, derived from your credentials on
    the server. There is no access to another customer's data.
  </Accordion>

  <Accordion title="Are outbound webhooks available?">
    Not today. Long-running operations are read by polling the relevant record
    until it's ready. Whether outbound webhooks ship later isn't confirmed or
    currently on the [Roadmap](/product-updates/roadmap).
  </Accordion>

  <Accordion title="Where's the full technical reference — exact fields, types, and operation names?">
    It publishes here once partner authentication ships. Publishing exact operation names ahead of access controls being in place is an exposure we avoid by design.
  </Accordion>
</AccordionGroup>

## Related

<CardGroup cols={2}>
  <Card title="Authentication" icon="key" href="/get-started/authentication">
    The scope model and the prerequisite that gates the API.
  </Card>

  <Card title="Bulk Ingest" icon="file-import" href="/supporting/bulk-ingest">
    The REST routes for loading candidates and jobs in bulk.
  </Card>

  <Card title="Jobs & Candidates" icon="briefcase" href="/supporting/jobs-candidates">
    The base entities every evaluation runs on.
  </Card>

  <Card title="Capabilities" icon="star" href="/capabilities/career-page">
    What each capability does and why you'd use it.
  </Card>
</CardGroup>