canonical: https://jentic.com/apis/ashbyhq.com/ashby

# Ashbyhq Ashby API

Jentic publishes the only available OpenAPI specification for Ashby API, keeping it validated and agent-ready. Ashby is an applicant tracking system (ATS) used by high-growth companies to manage the entire hiring funnel - sourcing, applications, interviews, offers, and analytics. The API exposes 157 RPC-style endpoints covering applications, candidates, jobs, interview schedules, feedback, offers, and approvals, secured with HTTP basic authentication using an API key. Endpoint naming follows a dot-notation convention (e.g. application.list, candidate.create) and all calls use POST.

## For AI agents

Manage the entire ATS hiring funnel - applications, candidates, interviews, feedback, and offers - across 157 RPC operations on the Ashby API.

## Scope

Does not handle payroll, HRIS records, or onboarding - use for applicant tracking, interview management, and offer workflows only.

## Capabilities

- Create candidate records and submit applications to specific job openings
- Move applications between hiring stages and change the assigned source
- Schedule interviews and pull interview feedback per applicant
- Generate and update offers tied to an application
- List approval workflows and add or remove hiring-team members
- Pull application history and criteria evaluations for audit reporting
- Transfer applications between jobs without losing candidate context

## Use cases

### Sourcing-to-Application Pipeline

Push candidates sourced from outbound tools or referral platforms directly into Ashby as new applications, with the right source attribution and job mapping. The application.create endpoint accepts a candidate and job pairing, while application.changeSource keeps attribution clean across the funnel. Reduces the manual data entry that recruiters typically do between sourcing tools and the ATS.

Example prompt: Create an Ashby application for candidate ID 'cand_123' on job 'job_456' with source 'LinkedIn Outbound' and confirm the application ID returned

### Interview Coordination and Feedback Aggregation

Use the applicationFeedback.list and related endpoints to aggregate interview feedback across panels and surface a consolidated view to hiring managers. Pair with application.changeStage to move candidates forward once feedback thresholds are met. Suitable for organisations running structured interview loops where consistency matters.

Example prompt: Pull all feedback for application 'app_789', score it against the rubric, and if average is above threshold call application.changeStage to advance the candidate

### Hiring Team Operations Dashboard

Build a live dashboard that lists open applications by hiring-team member and pulls criteria evaluations via application.listCriteriaEvaluations. Hiring managers see what's blocked, what needs feedback, and where approvals are pending. The approval.list endpoint surfaces offer-approval bottlenecks. Useful at scale where a recruiter manages dozens of active applications.

Example prompt: List all approvals via approval.list, identify any pending more than 48 hours, and summarise blocked applications by hiring manager

### AI Agent for Recruiting Operations

An agent integrated through Jentic can monitor new applications, advance candidates through stages based on feedback, and notify hiring managers about stalled offers - all without storing the Ashby API key. Jentic isolates the basic-auth credential in its vault and the agent uses Jentic's intent search to navigate Ashby's 157 RPC operations rather than browsing the docs.

Example prompt: Through Jentic, find all applications stuck at 'Onsite' for more than 5 days, list their feedback, and draft a follow-up message to the hiring manager

## Key endpoints

| Method | Path | Description |
| --- | --- | --- |
| POST | /application.create | Create a new application |
| POST | /application.list | List applications |
| POST | /application.changeStage | Move an application to a new stage |
| POST | /application.changeSource | Change the source attribution for an application |
| POST | /application.transfer | Transfer an application to a different job |
| POST | /application.listCriteriaEvaluations | List interview criteria evaluations |
| POST | /applicationFeedback.list | List feedback for an application |
| POST | /approval.list | List approval workflows |

## Key resources

- **Application** — Create, update, transfer, and stage applications through the hiring pipeline
- **Candidate** — Manage candidate records and link them to applications
- **ApplicationFeedback** — List and manage interview feedback per application
- **Approval** — Manage offer-approval workflows
- **Job** — Read job posting and opening data
- **ApiKey** — Inspect API key info

## Why Jentic

- **Setup:** Wiring Ashby by hand means encoding its API key as basic auth and learning its dot-notation RPC conventions across more than a hundred and fifty operations. Through Jentic you install once, import the Ashby API from the API Directory, store the key once, and your agent calls it.
- **Permission scoping:** Ashby uses dot-notation RPC operations that carry their target in the request body rather than a URL path, so limit the agent to the operations it needs, such as application.list or application.changeStage. You choose the operations it may call, so application.transfer is not included unless you add it.
- **Credential handling:** Your Ashby API key is stored once, encrypted, by your own Jentic One instance as a basic-auth credential and injected at execution time. It never enters the agent's prompt, logs, or context.
- **Discovery method:** Agents search Jentic by intent such as 'change an Ashby application stage', and Jentic returns the matching RPC operation with its input schema so the agent does not have to learn Ashby's dot-notation conventions.

## Related APIs

- **Greenhouse Harvest API** — Greenhouse Harvest is the long-established ATS API with broader integration coverage but a more verbose REST surface than Ashby's RPC style.
- **Lever** — Lever is a CRM-style ATS with strong nurture features, where Ashby leans into structured analytics.
- **Workable** — Workable serves SMB hiring teams; Ashby targets high-growth companies with structured interview loops.
- **BambooHR** — BambooHR handles HRIS records once Ashby finishes hiring; pair them for a hire-to-onboard flow.

## FAQ

### Why is there no official OpenAPI spec for Ashby API?

Ashby does not publish an OpenAPI specification. Jentic generates and maintains this spec so that AI agents and developers can call Ashby API via structured tooling. It is validated against the live API and kept up to date. Get started with Jentic One, the self-hosted execution layer.

### What authentication does the Ashby API use?

The API uses HTTP basic authentication. The Ashby API key is supplied as the username with an empty password, base64-encoded in the Authorization header. Jentic stores the key in its credential vault and constructs the basic-auth header at execution time.

### Why are all Ashby endpoints POST requests?

Ashby uses an RPC-style API where every operation is a POST to a dot-notation path such as /application.list or /candidate.create. There are no GET endpoints - read operations like application.list still POST a JSON body containing filters.

### Can I move an application to a new interview stage through the Ashby API?

Yes. POST /application.changeStage accepts an applicationId and the target stage identifier. Use POST /application.list first to discover the application's current stage and POST /application.listHistory for an audit trail of stage changes.

### What are the rate limits for the Ashby API?

The OpenAPI specification does not document explicit rate limits. Ashby publishes rate-limit headers on responses in production - implement exponential backoff on HTTP 429 and batch list calls rather than polling per-application.

### How do I list interview feedback through Jentic?

Search Jentic for 'list interview feedback for an Ashby application' - the POST /applicationFeedback.list operation will be returned. Load its schema, supply the applicationId, and execute. Jentic handles auth and returns the structured feedback array.

### Can I limit what my agent is allowed to do with the Ashby API?

Yes. Because Jentic One is self-hosted, you decide which of Ashby's dot-notation RPC operations your agent may call and which credentials it may use. You can grant read-and-advance operations like application.list and application.changeStage while withholding riskier ones such as application.transfer, which the agent cannot invoke unless you add it. The Ashby operations carry their target in the request body rather than a URL path, so this operation-level allowlist is what defines the agent's reach.