Skip to main content
The InstaView API gives you programmatic access to agents, contacts, conversations, runs, jobs, companies and billing. Every endpoint requires API key authentication.

Base URL

All API requests should be made to:

Authentication

All API requests require an API key in the Authorization header using the Bearer scheme:
For more information about authentication and API keys, see the Authentication Guide.

Resources

The API is organized around the following resources:
  • Agents - The AI that runs the call
  • Contacts - The people you call
  • Conversations - One call each, with its transcript and results
  • Runs - A batch of conversations one agent is working through
  • Jobs - Job postings, for the hiring focuses that need one
  • Companies - Company information (ATS keys only)
  • Billing - Usage statistics and billing information

Resource names

Two resources answer to two names. InstaView started in hiring, so its API was written in hiring nouns; agents now run sales, support and operations calls, where “interview” and “candidate” describe the wrong thing. Rather than cut a v2 whose only content is a rename, both names work: Nothing you have written stops working. The legacy paths are served by the same handlers, not a redirect: same request, same response, same scopes, same rate limits. They stay for the life of v1. If we ever cut a v2, it will be for a change worth migrating for, and the aliases will go with it. Three details worth knowing:
  • Responses carry both id names, always identical. A conversation returns contactId and candidateId with the same value, so you can move at your own pace, field by field.
  • Requests take either, but not both with different values. Sending contactId and candidateId set to two different ids is a 400 rather than a guess about which you meant. The same rule applies to the inline contact / candidate body on Create Conversation.
  • Either scope name works. read:conversations and read:interviews are the same permission, and holding one satisfies a requirement for the other — in both directions, for read:, write: and delete: alike. Your existing key keeps the scopes it already has and keeps working; there is nothing to migrate and no date by which to do it. Keys created from now on are issued with the neutral names, which is all that changed. See Scopes and Permissions.
jobs and agents are unchanged: agent is already neutral, and job has no better generic equivalent and is optional on a conversation anyway. So is analysis, along with sourcing and enrich — none of them was ever hiring-specific. A few names inside those resources kept their hiring spelling too, because they are the names the API accepts and returns. There is no alias for these, and nothing to migrate:

Response Format

A successful response returns the resource itself, with no wrapper around it:
List endpoints return a page object — the items in data, the counts beside it. See the Pagination Guide. Whether a call succeeded is carried by the HTTP status code, not by a field in the body. Every response also carries an x-trace-id header; quote it when you write to support.
Responses used to be wrapped in { statusCode, message, data, traceId }, which put list items at data.data. Integrations that predate this keep receiving the old shape until 4 September 2026, 00:00 Europe/Prague, and can tell because their responses carry a Sunset header until then. See the changelog for the before-and-after and what to change in your client.

Rate Limiting

API requests are rate-limited to ensure fair usage. See the Rate Limiting Guide for details.

Pagination

List endpoints support pagination using page and limit query parameters. See the Pagination Guide for details.

Error Handling

The API uses standard HTTP status codes and returns error details in a consistent format. See the Error Handling Guide for details.

Interactive Playground

Each endpoint documentation includes an interactive playground where you can test API calls directly from your browser. Look for the “Try It” button on any endpoint page.