Introduction
TL;DR Recruiting teams keep asking one question. Can the Ashby API carry a full recruiting stack, or does it only handle small tasks? This review answers that question with real details from Ashby’s own developer documentation. You get a plain look at endpoints, authentication, rate limits, webhooks, and pricing. By the end, you will know if the Ashby API fits your integration plans.
Table of Contents
What Is the Ashby API
The Ashby API sits at api.ashbyhq.com. It gives developers programmatic access to Ashby’s applicant tracking system. Ashby built the platform for candidates, applications, jobs, interviews, offers, and scheduling data. Every endpoint uses the POST method. This design surprises developers who expect standard REST behavior with GET requests for reads. Ashby chose an RPC-style pattern instead. You send a POST request even when you only want to fetch a list of candidates.
Ashby markets itself as an all-in-one recruiting platform. It bundles an applicant tracking system, a sourcing CRM, interview scheduling, and analytics into one product. The Ashby API mirrors that scope. It does not stretch into unrelated categories like contact enrichment or company intelligence. It stays focused on hiring workflows from the first application to the signed offer.
Who Actually Uses the Ashby API
Recruiting operations teams reach for the Ashby API first. They build internal dashboards that pull live pipeline data. Engineering teams at high-growth startups use it next. They connect Ashby to Slack, data warehouses, and custom career sites. Integration platforms like Merge, Knit, Truto, and Stitchflow also build on the Ashby API. They resell that connection as a managed sync for companies that skip custom development.
Core Capabilities Worth Knowing
The Ashby API covers candidate creation, application updates, interview scheduling, feedback submission, job posting management, and offer workflows. It also exposes organizational data such as departments, locations, and custom fields. A separate public job board endpoint lets you pull live postings without any authentication at all. That endpoint powers most custom career pages built on top of Ashby.
Ashby API Authentication and Security
Security questions come up fast once a team commits to the Ashby API. The setup uses HTTP Basic Authentication. Your API key becomes the username. The password field stays blank. This differs from the Bearer token pattern many modern APIs use, so plan your HTTP client configuration around it early.
Generating and Scoping API Keys
Admins create API keys inside the Ashby settings panel under Integrations. Each key carries its own permission scopes. You pick exactly which modules that key can touch. A key built for a job board sync only needs job read access. A key built for a full recruiting integration might need candidate write access, application write access, and interview scheduling access together. This scoped design limits damage if one key leaks.
Permission Scopes and Module Access
Ashby splits permissions by module and by action. You see options like candidatesRead, candidatesWrite, applicationsRead, jobsWrite, and organizationRead. A single Ashby API key can carry multiple scopes at once, but narrow scoping stays the safer practice. Grant only what a given integration needs. Rotate keys on a schedule instead of leaving one key active for years.
Confidential Data Handling
Confidential jobs and private candidate fields stay hidden from Ashby API responses by default. Your organization must flip a setting per key to expose that data. Teams that skip this step often assume their sync is broken when records simply come back incomplete. Check your key permissions first if confidential roles or private fields go missing from a response.
Ashby API Endpoints Explained
The endpoint list runs deep. Recent documentation counts over 160 distinct paths across candidates, applications, feedback, interviews, schedules, jobs, job postings, offers, openings, departments, locations, custom fields, surveys, assessments, referrals, sources, users, and reports. That breadth puts the Ashby API ahead of many smaller ATS platforms on raw coverage.
Candidate and Application Endpoints
Candidate endpoints let you create profiles, update contact details, attach resumes, and search existing records. Application endpoints move a candidate through pipeline stages, log activity, and pull application history. A typical sourcing integration writes new candidates through candidate.create, then attaches them to a job through application.create. This pairing forms the backbone of most custom sourcing tools built on the Ashby API.
Interview and Scheduling Endpoints
Interview endpoints cover scheduling, rescheduling, and feedback submission. You can pull a candidate’s full interview history or push structured feedback from an external tool back into Ashby. Scheduling endpoints work well for teams that build custom coordination tools outside Ashby’s native scheduler.
Job and Job Posting Endpoints
Job endpoints manage open roles, departments, and job boards. Job posting endpoints control what shows on a public careers page. Many companies use these endpoints to sync open roles into a custom-built jobs page that matches their brand instead of using Ashby’s hosted board directly.
Offer, Department, and Reporting Endpoints
Offer endpoints track compensation details and approval status through the closing stage of a hire. Department and location endpoints supply the organizational data that most reporting integrations need for context. Reporting endpoints pull aggregated pipeline metrics, which teams often route into a data warehouse for executive dashboards.
Custom Fields, Surveys, and Assessment Endpoints
Ashby extends its data model past the standard candidate record. Custom field endpoints let you read and write organization-specific attributes, such as a referral source or an internal ranking score. Survey endpoints pull structured feedback from candidates after an interview or after a rejection. Assessment endpoints connect coding tests and skills evaluations back into a candidate’s profile. A recruiting stack built on the Ashby API can pull every one of these signals into a single scoring model without leaving Ashby’s data boundary.
User, Source, and Referral Endpoints
User endpoints return the list of Ashby seats inside your organization, along with their roles. Source endpoints track where each candidate originated, whether that means a job board, an agency, or an employee referral. Referral endpoints capture and manage internal referral submissions directly. Teams building internal mobility tools or referral bonus trackers lean on these three endpoint groups most.
Ashby API and Third-Party Integration Platforms
Not every team wants to write raw HTTP calls against the Ashby API. A growing set of integration platforms now sit between Ashby and the rest of your stack. Merge exposes a unified ATS API that normalizes Ashby alongside Greenhouse, Lever, and other systems behind one schema. Knit and Truto take a similar approach, adding managed authentication and error handling on top of the raw Ashby API. Airbyte and Stitchflow focus more narrowly on data movement, syncing Ashby records into a warehouse or into an identity management tool on a schedule.
These platforms trade flexibility for speed. You lose some control over exact request shape, but you skip weeks of plumbing work around pagination, retries, and the success-false quirk mentioned earlier. A small team with a tight deadline often starts here, then migrates to a direct Ashby API integration later once the use case grows past what a generic connector supports.
Ashby API Rate Limits and Performance
Rate limits shape how far you can push any integration. Ashby does not publish a fixed number in its main documentation. Independent connector documentation from data platforms points to a working limit near 1,000 requests per minute per key for standard endpoints. Treat that figure as a practical guide rather than an official guarantee, since Ashby reserves the right to adjust it without notice.
Building Backoff Logic Without Published Headers
Ashby does not return standard rate-limit headers on every response. Your integration should still assume throttling can happen at any moment. Build exponential backoff into every Ashby API client from day one. A 429 response should trigger a wait and retry, not a hard failure. This habit protects your sync jobs from breaking during high-traffic hiring seasons.
The Success False Quirk Every Integrator Should Know
Here is a detail that trips up new developers constantly. Ashby sometimes returns an HTTP 200 status code even when a request fails. The response body carries a success: false flag instead of a standard error code. Any integration that only checks HTTP status will miss real failures. Parse the response body on every call. Check that success field before you trust a write actually happened. This single quirk causes more silent bugs than any rate limit ever will.
Ashby API Webhooks
Webhooks turn the Ashby API from a request-response tool into a real-time system. Instead of polling for changes, your integration listens for events and reacts instantly. Ashby fires webhooks for application submissions, candidate stage changes, hires, and several other pipeline events.
Supported Webhook Events
applicationSubmit fires when a candidate applies or gets added manually. candidateStageChange fires when a candidate moves between pipeline stages. candidateHire fires on a completed hire and also triggers the related application and stage-change events automatically. This event chaining lets a single hire action update several parts of a connected system at once without extra polling.
Signature Verification and Retry Behavior
Every webhook payload carries a cryptographic signature. Your receiving endpoint should verify that signature before trusting any payload. This step blocks spoofed requests from hitting your system. Ashby also retries failed webhook deliveries with exponential backoff, so a brief outage on your end rarely causes permanent data loss. Build your webhook receiver to acknowledge quickly and process asynchronously for the smoothest results.
Ashby API Security and Compliance Considerations
Recruiting data carries real sensitivity. Candidate resumes, compensation details, and interview feedback all count as data that deserves careful handling. The Ashby API supports this through scoped permissions and hidden confidential fields, but the responsibility does not stop there. Store every API key in a secrets manager rather than a plain configuration file. Log request activity so you can trace an unexpected data change back to its source. Rotate keys whenever a team member with key access leaves the company.
Ashby also supports SCIM for automated user provisioning through an identity provider. This feature handles account creation and deactivation, but it does not map roles or permissions from your identity provider into Ashby. Every SCIM-provisioned user lands with limited access by default. A recruiting ops admin still needs to elevate roles manually inside the Ashby panel after provisioning runs. Teams that assume SCIM handles the full onboarding flow often get surprised by this gap during an audit.
Ashby API Compared to Other ATS APIs
Recruiting teams often weigh Ashby against Greenhouse, Lever, and Workday before committing engineering time. Each platform takes a different approach to developer access.
Documentation and Developer Experience
Ashby publishes its full API reference without a login wall. You get an interactive interface, a downloadable OpenAPI spec, and a Postman collection ready to import. Greenhouse offers similarly open documentation. Workday locks much of its integration detail behind partner agreements and sales conversations. For a small team without a dedicated integrations budget, the open Ashby API documentation removes a real barrier to getting started.
Scope and Limitations Compared
Lever and Greenhouse both cover similar ground: candidates, applications, jobs, and interviews. None of these platforms stretch into contact enrichment or firmographic data, since that sits outside what an ATS is built for. The real differentiator among them comes down to rate limit transparency and SDK support. Ashby currently ships no official SDK, while some competitors offer at least a community-maintained client library in common languages.
Building Your Recruiting Stack on the Ashby API
This is the core question behind this review. Can a team realistically build a full recruiting stack on the Ashby API? The honest answer depends on scope.
Custom Career Page Integration
The public job posting endpoint makes custom career pages simple to build. You pull live job data without any authentication, format it to match your brand, and skip Ashby’s hosted board entirely. Many fast-growing companies use exactly this pattern today.
CRM and Sourcing Tool Sync
Sourcing teams often want candidate data flowing both directions between Ashby and a separate CRM tool. The Ashby API supports this through candidate and application endpoints, paired with webhooks for real-time updates. Build careful deduplication logic here, since sourced candidates can enter through multiple channels at once.
Analytics and Reporting Pipelines
Reporting endpoints combined with department and location data give analytics teams enough raw material for custom dashboards. Most teams pull this data on a schedule into a warehouse, then layer visualization tools like Looker or Tableau on top. This pattern avoids hammering the Ashby API with live queries from every dashboard refresh.
AI Agent and Automation Workflows
Newer integration platforms now connect AI agents directly to the Ashby API for tasks like automated candidate outreach and offer status updates. These setups need careful error handling because of the success-false quirk covered earlier. An agent that trusts a 200 status blindly will report false successes to a recruiter, which erodes trust in the automation fast.
Ashby API Pricing and Access
API access comes bundled with every paid Ashby plan rather than sitting behind a separate add-on fee. Entry-level plans start in the low hundreds of dollars per month, scaling up based on headcount and feature tier. This bundled approach removes a common friction point that other platforms create when they charge extra for API access on lower tiers. Confirm current pricing directly with Ashby sales before budgeting, since ATS pricing shifts often as vendors adjust packaging.
Common Ashby API Challenges
No API comes without friction. Three issues show up repeatedly across developer forums and integration case studies.
No Official SDKs
Ashby ships no official SDK in any language. You write raw HTTP calls yourself or lean on a third-party client from a platform like Merge or Knit. This adds setup time for small teams without spare engineering capacity, though it also means you avoid dependency bloat from an unofficial wrapper library.
Undocumented Rate Limits
The lack of a published rate limit number forces teams into trial and error. You discover real limits through testing or through a support conversation rather than a documentation page. Build conservative request pacing from the start rather than pushing limits blindly.
No Sandbox Environment
Ashby does not provide a public sandbox for testing integrations safely. Teams either build against a restricted-permission production key or set up a dedicated test workspace inside their real account. Either path adds setup overhead compared to platforms that ship a dedicated sandbox out of the box.
Is the Ashby API Right for Your Recruiting Stack
A small team automating one or two workflows will find the Ashby API more than capable. Candidate creation, stage automation, and webhook-driven notifications all work reliably once you handle the success-false quirk correctly. A larger team trying to replace Ashby’s entire interface with a fully custom tool faces more friction, mostly from missing SDKs and undocumented limits rather than missing functionality.
The endpoint coverage itself rarely becomes the blocker. Most teams that struggle with the Ashby API hit friction around operational details: silent failures, backoff logic, and permission scoping. Plan for these from the first sprint and the Ashby API becomes a dependable foundation rather than a source of surprises.
Frequently Asked Questions
Does the Ashby API support GET requests? No. Every endpoint, including reads, uses the POST method. This RPC-style design differs from typical REST APIs, so update your client code expectations before you start building.
What authentication method does the Ashby API use? The Ashby API uses HTTP Basic Authentication. Your API key goes in the username field. The password field stays empty. Bearer-style tokens do not apply here.
Are there official SDKs for the Ashby API? Ashby does not maintain an official SDK in any language today. Developers write raw HTTP requests or use a third-party integration platform such as Merge, Knit, or Truto to skip that setup work.
What are the Ashby API rate limits? Ashby does not publish an official rate limit figure in its core documentation. Community and connector sources report a practical limit near 1,000 requests per minute per key for standard endpoints, though this can change without notice.
Does the Ashby API support webhooks? Yes. Webhooks cover events like application submissions, stage changes, and hires. Every payload carries a cryptographic signature for verification, and failed deliveries retry automatically with exponential backoff.
Can I build a custom career page with the Ashby API? Yes. A public job posting endpoint returns live job data without any authentication required. Many companies use this endpoint to build a fully custom careers page that keeps their own branding instead of Ashby’s hosted board.
Why does my Ashby API integration show success even when a write fails? Ashby sometimes returns a 200 status code alongside a success: false flag in the body. Always parse that field directly. Never trust the HTTP status code alone when you confirm whether a write actually succeeded.
Is the Ashby API included in every pricing plan? Yes. API access ships with every paid Ashby plan rather than sitting behind a separate charge, which keeps the barrier to entry lower than some competing platforms.
Does Ashby offer a sandbox for testing the API? No public sandbox exists today. Most teams test against a restricted-permission key inside their real workspace, or they set up a separate internal workspace strictly for development work before touching live candidate data.
Can the Ashby API power a fully custom applicant tracking interface? It can support most of the workflow, including candidates, applications, interviews, and offers. A team attempting this should budget extra time for the missing SDK, undocumented limits, and the success-false quirk, since none of Ashby’s native interface conveniences carry over automatically.
How does the Ashby API compare to Merge or Knit for a first integration? Merge and Knit remove setup work around authentication, retries, and pagination, which suits a team on a tight deadline. A direct Ashby API integration gives full control over request shape and timing, which suits a team planning a deep, long-term build.
Read More:-Marketo Microsoft Dynamics CRM Integration: Setup Guide [2026]
Conclusion
The Ashby API gives recruiting teams real, practical control over their hiring workflows. Candidate management, scheduling, offers, and reporting all sit within reach through a well-documented, broad set of endpoints. The lack of an official SDK and a published rate limit adds friction, but neither blocks a serious integration effort. Handle the success-false quirk correctly, scope your permissions with care, and build backoff logic from the start. Do this, and the Ashby API becomes a solid piece of a modern recruiting stack rather than a limitation on it. Teams that respect its quirks get a flexible, dependable system. Teams that skip the details run into avoidable bugs. Treat the Ashby API like production infrastructure from day one, and it holds up well through 2026 and beyond.
