Ashby is an all-in-one recruiting platform that combines applicant tracking, sourcing, analytics, scheduling, and CRM capabilities for high-growth talent teams. The Ashby REST API exposes applications, candidates, jobs, openings, offers, interview schedules, feedback, job postings, custom fields, and supporting reference data (departments, locations, sources, brands, tags, and users), enabling integrations to sync hiring data into warehouses, programmatically create or update candidates and jobs, manage offers and openings, and automate downstream recruiting workflows.
Power end-to-end data operations for your Ashby API with Nexla. Our bi-directional Ashby connector is purpose-built for Ashby, making it simple to ingest data, sync it across systems, and deliver it anywhere — all with no coding required. Nexla turns API-sourced data into ready-to-use, reusable data products and makes it easy to send data to Ashby or any other destination. With comprehensive monitoring, lineage tracking, and access controls, Nexla keeps your Ashby workflows fast, secure, and fully governed.
Features
Type: API
SourceDestination
Seamless API Integration: Connect to any endpoint as source or destination without coding, with automatic data product creation
Visual Composition & Chaining: Build complex integrations using visual templates, chain API calls, and compose workflows with data validation and filtering
API Proxy: Expose curated slices of your data securely with a secure and customizable API proxy that validates and transforms data on the fly
Request optimization with intelligent batching, retry, and caching to minimize API calls and costs
The Ashby REST API uses HTTP Basic Authentication. An Ashby admin generates an API key in the Ashby admin panel and provides that key to Nexla. The key is passed as the Basic Auth username with the password left blank, per Ashby's authentication specification.
API keys can only be created by Ashby admins, and they are tied to a specific set of permissions (read/write per resource module). Plan the integration's required permissions before creating the key.
Enter a descriptive name for the key in the Name field — for example, Nexla Integration. Names help identify the key in audit logs if multiple keys are issued.
Optionally, select an Integration Partner if Ashby offers a preset profile for the integration target. This is not required for Nexla — leaving the field blank is fine.
Configure endpoint permissions. By default, the new key has no permissions. Use the checkboxes to grant Read or Write access per resource module (Candidates, Applications, Jobs, Openings, Offers, Interview Schedules, Custom Fields, and so on). Grant the minimum permissions required for the planned data flows:
Read scopes are sufficient for source-only flows that ingest data from Ashby into Nexla.
Write scopes are required to use the destination endpoints listed on the data destination page (Create/Update Candidate, Create/Update Job, Create Application, Start Offer Process, etc.).
Decide whether the key should be able to access confidential jobs. Confidential jobs are normally hidden from non-authorized users in Ashby — enable this option only if the integration must include confidential jobs in its data set.
Click Save and Continue.
On the final step, copy the API key value and store it in a secure secret manager. Treat this value like a password — it grants the configured access to your Ashby account data.
Ashby displays the API key value only once at the moment of creation. If the key is lost, it must be revoked and a new key issued. Rotate keys promptly if exposure is suspected.
The Ashby API key grants the configured access to your Ashby account data. Store it in a secure secret manager, never commit it to source control, and rotate it immediately if you suspect it has been exposed.
After selecting the data source/destination type, click the Add Credential tile to open the Add New Credential overlay.
Enter a name for the credential in the Credential Name field and a short, meaningful description in the Credential Description field.
Enter your Ashby API key in the API Key field. Nexla passes this value as the HTTP Basic Auth username on every request and sends an empty password, exactly as Ashby's authentication spec requires — no additional configuration is needed to follow the Ashby Basic Auth convention.
The API key controls what data Nexla can read or write in Ashby. If the key was issued with read-only scopes, write-oriented destination endpoints (such as Create Candidate or Update Job) will return permission errors at runtime. Re-issue the key with the additional scopes if write operations are needed.
Click the Save button at the bottom of the overlay. The newly added credential will now appear in a tile on the Authenticate screen during data source/destination creation and can be selected for use with a new data source or destination.
To create a new data flow, navigate to the Integrate section, and click the New Data Flow button. Select the Ashby connector tile from the list of available connectors, then select the credential that will be used to connect to the Ashby instance, and click Next; or, create a new Ashby credential for use in this flow.
Nexla provides pre-built templates that can be used to rapidly configure data sources to ingest data from common Ashby endpoints. Each template is designed specifically for the corresponding Ashby endpoint, making data source setup easy and efficient.
All Ashby read endpoints are accessed via POST against https://api.ashbyhq.com/{resource}.{action} (for example, POST /candidate.list, POST /application.info). Filters and pagination cursors are passed in the request body. Each template handles this convention automatically.
Select the endpoint from which this source will fetch data from the Endpoint pulldown menu. Available endpoint templates are listed in the expandable boxes below. Click on an endpoint to see more information about it and how to configure your data source for this endpoint.
List Applications
This endpoint retrieves a paginated list of applications in the Ashby account, with optional filters for status, job, and creation date. Use it to sync the application pipeline into a warehouse, build hiring funnel reports, or feed downstream CRMs.
All filter parameters on this endpoint are optional. Leave them blank to return all applications, or set specific values to narrow the result set.
Enter an ISO 8601 timestamp in the Created After field to return only applications created at or after that time — useful for incremental syncs on a schedule.
Enter the Sync Token returned by a previous request to fetch only the records that changed since that token was issued. This is the recommended approach for ongoing incremental syncs.
Enter a value in the Status field (for example, Active, Hired, Archived) to restrict results to applications in that state.
Enter a job ID in the Job ID field to scope results to a single job. Job IDs can be obtained from the List Jobs endpoint.
Enter a comma-separated list of related fields in the Expand field (for example, candidate,job) to inline related objects in the response and reduce subsequent lookup calls.
Pagination uses Ashby's cursor scheme — Nexla advances the cursor token automatically using the nextCursor field returned by each response. For incremental syncs, persist the Sync Token from the last response and pass it back on the next run.
Get Application
This endpoint returns full details for a single application by ID. Use it to enrich an existing dataset of application IDs with current status, candidate, job, and form data.
Enter the application ID in the Application ID field. This field is required. Application IDs can be obtained from the List Applications endpoint or from upstream Nexla data flows.
List Application Feedback
This endpoint returns all interview scorecards and feedback submissions associated with applications. Use it to power interviewer performance dashboards, calibration reports, or candidate quality analytics.
The Cursor field is optional and is managed by Nexla's pagination — leave it blank for normal usage.
Enter the maximum number of feedback records to return per page in the Limit field. The default value is 100.
List Application Criteria Evaluations
This endpoint returns evaluations of applications against configured hiring criteria. Use it for structured-interview reporting or to feed downstream analytics that compare candidates against role-specific rubrics.
No configuration is required for this endpoint beyond selecting it. Pagination is managed automatically by Nexla.
List Candidates
This endpoint retrieves a paginated list of candidates in the organization. Use it to sync the candidate database into a warehouse, marketing platform, or sourcing CRM.
Enter an ISO 8601 timestamp in the Created After field to return only candidates created at or after that time.
Enter the Sync Token returned by a previous request to fetch only the records that changed since that token was issued.
For incremental syncs, prefer Sync Token over Created After — Ashby's sync token captures updates to existing records, not just newly created ones.
Get Candidate
This endpoint returns full details for a single candidate by ID, including contact information and metadata.
Enter the candidate ID in the Candidate ID field. This field is required. Candidate IDs can be obtained from the List Candidates endpoint.
Search Candidates
This endpoint searches candidates by name or email. Results are capped at 100 per request. Use it to find candidates ad-hoc from upstream data — for example, to check whether an inbound lead already exists as a candidate.
Enter an email address in the Email field to search for candidates with that email.
Enter a full or partial name in the Name field to search for candidates by name.
At least one of the two search fields should be populated. Leaving both blank returns no results.
List Candidate Tags
This endpoint returns the full catalog of candidate tags configured in Ashby. Use it as a reference dataset for downstream systems that need to display or filter on tag values.
No configuration is required for this endpoint beyond selecting it. All tags are returned automatically.
List Jobs
This endpoint returns a paginated list of jobs with optional filters for status, open/close dates, and other criteria. Use it to sync the job catalog into a warehouse or feed downstream career-site or analytics tools.
Enter an ISO 8601 timestamp in the Created After field to limit results to jobs created at or after that time.
Enter the Sync Token returned by a previous request for incremental syncs.
Enter a value in the Status field (for example, Open, Draft, Closed, Archived) to filter by current status.
Use the Opened After / Opened Before fields to filter by job opening date, and Closed After / Closed Before to filter by closing date. Dates use the format YYYY-MM-DD.
Enter a comma-separated list of related fields in the Expand field to inline related objects in the response.
Get Job
This endpoint returns full details for a single job by ID, including title, team, location, and interview-plan metadata. Use it to enrich a dataset of job IDs with current job state.
The job ID must be supplied in the request body when the call is made. When this template is driven by an upstream Nexla source (such as List Jobs), use the manual configuration to substitute the upstream record's id field into the body template.
Search Jobs
This endpoint searches jobs by title. Use it to look up specific roles by name from upstream systems — for example, mapping requisition titles from an HRIS into Ashby job IDs.
Enter the job title (or partial title) to search for in the Title field.
List Job Postings
This endpoint returns job postings (the publishable, candidate-facing description of a job) with optional filters for location, department, board, and visibility. Use it to power career-site mirrors or feed downstream job boards.
Enter a value in the Location field to restrict postings to a specific location name.
Enter a value in the Department field to restrict postings to a specific department.
Set the Listed Only field to true to return only publicly-listed postings, or false to include unlisted/internal postings.
Enter a job board ID in the Job Board ID field to restrict results to postings published to a specific board.
Get Job Posting
This endpoint returns full details for a single job posting by ID, including the application-form definition. Use it to render or mirror posting content (description, locations, application form fields) in a downstream system.
Enter the job posting ID in the Job Posting ID field. This field is required. Job posting IDs can be obtained from the List Job Postings endpoint.
List Openings
This endpoint returns a paginated list of job openings (individual headcount slots beneath a job) with optional filtering by creation date.
Enter an ISO 8601 timestamp in the Created After field to limit results to openings created at or after that time.
Enter the Sync Token returned by a previous request for incremental syncs.
Search Openings
This endpoint searches for a specific opening by identifier (the external opening identifier configured in Ashby).
Enter the opening identifier in the Identifier field. This field is required.
List Offers
This endpoint returns a paginated list of offers with optional filters for offer status, acceptance status, approval status, and application. Use it to power offer dashboards, compensation reports, or downstream HRIS handoff.
Enter an ISO 8601 timestamp in the Created After field to limit results to offers created at or after that time.
Enter the Sync Token returned by a previous request for incremental syncs.
Use the Offer Status, Acceptance Status, and Approval Status fields to filter on those workflow states.
Enter an application ID in the Application ID field to scope results to offers for a single application.
List Projects
This endpoint returns a paginated list of sourcing projects, optionally filtered by creation date. Use it to sync sourcing pipeline data into downstream tools.
Enter an ISO 8601 timestamp in the Created After field for incremental ingestion.
Enter the Sync Token returned by a previous request for incremental syncs.
Search Projects
This endpoint searches sourcing projects by title.
Enter the project title (or partial title) to search for in the Title field.
List Interviews
This endpoint returns a paginated list of all interviews configured in Ashby. Use it to feed interview-load dashboards or to sync interview metadata into a warehouse.
No configuration is required for this endpoint beyond selecting it. Pagination is managed automatically by Nexla.
List Interview Stages
This endpoint returns all interview stages configured in Ashby. Use it as a reference dataset for funnel analytics or stage-based reporting.
No configuration is required for this endpoint beyond selecting it. All interview stages are returned automatically with cursor pagination managed by Nexla.
List Interview Schedules
This endpoint returns a paginated list of interview schedules, optionally filtered by application or interview stage. Use it to power scheduling dashboards, sync interview calendars into BI, or feed downstream calendar tools.
Enter an ISO 8601 timestamp in the Created After field for incremental ingestion.
Enter an application ID in the Application ID field to scope results to a single application.
Enter an interview stage ID in the Interview Stage ID field to scope results to a single stage.
List Feedback Form Definitions
This endpoint returns all feedback form definitions configured in Ashby (the scorecard structures used during interviews). Use it as a reference dataset for analyzing feedback submitted via List Application Feedback.
No configuration is required for this endpoint beyond selecting it. All feedback form definitions are returned automatically.
List Communication Templates
This endpoint returns all communication templates configured in the Ashby account — for example, candidate-facing email templates used during outreach and stage transitions.
No configuration is required for this endpoint beyond selecting it. All templates are returned automatically.
List Custom Fields
This endpoint returns all custom fields configured in the Ashby account, across all object types. Use it as a schema-discovery dataset when downstream systems need to render or map custom field values.
No configuration is required for this endpoint beyond selecting it. Pagination is managed automatically by Nexla.
List Archive Reasons
This endpoint returns all archive reasons available in the Ashby account. Archive reasons are used when applications are archived (for example, Position Filled, Withdrew, Not a Fit). Use it as a reference dataset for pipeline analytics.
No configuration is required for this endpoint beyond selecting it. All archive reasons are returned automatically.
List Close Reasons
This endpoint returns the list of reasons a job can be closed (for example, Filled, Cancelled), optionally including archived reasons. Use it as a reference dataset for job-status analytics.
Set the Include Archived field to true to include archived close reasons in the results, or leave it blank to return only active reasons.
List Brands
This endpoint returns a paginated list of brands configured in the organization. Brands are used in Ashby to support multi-brand recruiting (for example, a parent company with multiple consumer brands).
Enter the maximum number of brands to return per page in the Limit field. Leave blank to use the Ashby default.
List Departments
This endpoint returns all departments configured in the Ashby account. Use it as a reference dataset when grouping jobs or applications by org structure.
No configuration is required for this endpoint beyond selecting it. All departments are returned automatically.
List Locations
This endpoint returns the office locations configured in the Ashby account, with options to include archived locations and the parent/child location hierarchy.
Set the Include Archived field to true to include archived locations in the results.
Set the Include Location Hierarchy field to true to return parent-child relationships between locations.
List Sources
This endpoint returns all candidate sources configured in the Ashby account (for example, LinkedIn, Employee Referral, Company Site). Use it as a reference dataset for source attribution analytics.
No configuration is required for this endpoint beyond selecting it. All sources are returned automatically.
List Users
This endpoint returns a paginated list of users in the Ashby account (the internal recruiters, hiring managers, and interviewers), with optional inclusion of deactivated users.
Set the Include Deactivated field to true to include deactivated users in the results, or leave it blank to return only active users.
Once the selected endpoint template has been configured, click the Test button to the right of the endpoint selection menu to retrieve a sample of the data that will be fetched. Sample data will be displayed in the Endpoint Test Result panel on the right, allowing you to verify that the source is configured correctly before saving.
Ashby data sources can also be manually configured to ingest data from any valid Ashby API endpoint, including endpoints not covered by the pre-built templates, chained API calls (for example, listing applications and then fetching the feedback for each), or custom request bodies, pagination cursors, and response parsing. Select the Advanced tab at the top of the configuration screen, and follow the instructions in Connect to Any API to configure the API method, endpoint URL, date/time and lookup macros, path to data, metadata, and request headers.
All Ashby read endpoints use POST against the base https://api.ashbyhq.com/ followed by the resource and action (for example, https://api.ashbyhq.com/candidate.list, https://api.ashbyhq.com/application.info); filters and pagination cursors are passed in the request body.
Ashby list and search endpoints return data under a top-level results array, so the path to data is $.results[*]; info endpoints return a single object, so the path to data is $.results.
Ashby's paginated endpoints use a cursor scheme — set the pagination type to Next Token, the page-size parameter to limit, the cursor parameter to cursor, and the next-token path to $.nextCursor. To resume incremental syncs, capture the top-level syncToken returned by list endpoints as record metadata. The Authorization header for HTTP Basic Auth and Content-Type: application/json are added automatically for POST requests.
Once all of the relevant settings have been configured, click the Create button in the upper right corner of the screen to save and create the new Ashby data source. Nexla will now begin ingesting data from the configured endpoint and will organize any data that it finds into one or more Nexsets.
Click the + icon on the Nexset that will be sent to the Ashby destination, and select the Send to Destination option from the menu. Select the Ashby connector from the list of available destination connectors, then select the credential that will be used to connect to the Ashby account, and click Next; or, create a new Ashby credential for use in this flow.
Nexla provides pre-built templates that can be used to rapidly configure destinations to send data to common Ashby endpoints. Each template is designed specifically for the corresponding Ashby endpoint, making destination setup easy and efficient.
All Ashby write endpoints accept POST requests with a JSON body. Each upstream Nexset record is serialized as the body of a single request, so the upstream record's field names must match the field names Ashby expects for that endpoint.
Select the endpoint to which data will be sent from the Endpoint pulldown menu. Then, click on the template in the list below to expand it, and follow the instructions to configure additional endpoint settings.
Create Application
This endpoint creates a new application for a candidate against a job in Ashby. Use it to programmatically move a sourced candidate into a hiring pipeline, or to mirror application records inbound from an external sourcing tool.
Each record in the upstream Nexset must include the fields Ashby requires to create an application — at minimum a candidateId and a jobId (both obtainable from List Candidates and List Jobs source endpoints). Optional fields include sourceId, creditedToUserId, and interviewPlanId.
The full upstream record is sent as the JSON body of the POST /application.create call. Use the Nexla transform layer to shape upstream attributes into the field names expected by Ashby.
This endpoint updates properties of an existing application — for example, advancing the interview stage, updating custom field values, or reassigning the credited recruiter.
Each upstream record must include the applicationId of the application to update, plus any fields that should be changed. Omitted fields are left untouched.
The full upstream record is sent as the JSON body of the POST /application.update call.
Create Candidate
This endpoint creates a new candidate profile with contact information and metadata. Use it to seed Ashby with candidates sourced from upstream systems such as sourcing tools, referral platforms, or ATS migrations.
Each record in the upstream Nexset must include at minimum the candidate's name. Common optional fields include email, phoneNumber, linkedInUrl, githubUrl, website, alternateEmailAddresses, sourceId, creditedToUserId, and location.
The full upstream record is sent as the JSON body of the POST /candidate.create call.
Ashby deduplicates candidates by email. Including a candidate's email helps Ashby attach the new record to any existing profile rather than creating a duplicate.
Update Candidate
This endpoint updates the profile information of an existing candidate. Use it to keep candidate contact details in sync with a system of record such as a CRM.
Each upstream record must include the candidateId of the candidate to update, plus the fields to apply. Omitted fields are left untouched.
The full upstream record is sent as the JSON body of the POST /candidate.update call.
Create Job
This endpoint creates a new job in Ashby. Use it to provision roles directly from an HRIS, headcount-planning tool, or internal requisition system.
Each record in the upstream Nexset must include the fields Ashby requires to create a job — typically title, departmentId, and locationId. Common optional fields include teamId, jobTemplateId, and defaultInterviewPlanId.
The full upstream record is sent as the JSON body of the POST /job.create call.
Update Job
This endpoint updates an existing job with new information such as title, team, location, or default interview plan. Use it to keep job metadata in sync with an upstream system of record.
Each upstream record must include the jobId of the job to update, plus the fields to apply.
The full upstream record is sent as the JSON body of the POST /job.update call.
Get Job
This destination template wraps Ashby's POST /job.info endpoint and is typically used in FlexFlow scenarios where the upstream record drives a job lookup (for example, to validate a job ID before issuing a downstream action).
Each upstream record must include the id field with the job ID to look up. The full record is sent as the JSON body of the POST /job.info call.
Enable the Response Webhook option (in the Manual configuration section below, after switching to the Advanced tab) to capture the API response into a Nexla webhook source for downstream branching.
Create Opening
This endpoint creates a new job opening (an individual headcount slot under a job). Use it to mirror approved headcount from a headcount-planning tool or finance system.
Each upstream record must include the fields Ashby requires for an opening — typically a jobId (the parent job) and an identifier for the opening. Other common fields include openingState, openedAt, and targetHireDate.
The full upstream record is sent as the JSON body of the POST /opening.create call.
Update Opening
This endpoint updates an existing job opening with new details such as state transitions, target hire date, or budget.
Each upstream record must include the openingId of the opening to update, plus the fields to apply.
The full upstream record is sent as the JSON body of the POST /opening.update call.
Set Multiple Custom Field Values
This endpoint sets multiple custom field values for a specified object in Ashby in a single call. Use it to backfill custom field data from an upstream system without issuing one call per field.
Each upstream record must specify the target object (typically objectType and objectId) and an array of fieldValues containing the custom field IDs and values to set. Custom field IDs can be obtained from the List Custom Fields source endpoint.
The full upstream record is sent as the JSON body of the POST /customField.setValues call.
Use the Nexla transform layer to assemble the fieldValues array — for example, by mapping upstream column names to the corresponding Ashby custom field IDs.
Start Offer Process
This endpoint initiates the offer process for a specific application. Use it to programmatically kick off Ashby's offer workflow when an upstream system signals that a candidate is ready for an offer (for example, after final interview approval in a separate system of record).
Each upstream record must include the applicationId of the application to start the offer for, plus any additional fields required by the configured offer process in Ashby.
The full upstream record is sent as the JSON body of the POST /offerProcess.start call.
Starting an offer process triggers downstream notifications and approval routing in Ashby. Validate upstream data carefully before activating this destination — consider routing through a Nexla transform that filters to only the applications that should genuinely receive offers.
Ashby destinations can also be manually configured to send data to any valid Ashby API endpoint not covered by the pre-built templates. Manual configuration can also send the response received from the Ashby API after each call to a new Nexla webhook data source — particularly useful for capturing IDs returned by create endpoints (such as the new candidate ID from Create Candidate) so they can be used in downstream Nexla flows. Select the Advanced tab at the top of the configuration screen, and follow the instructions in Connect to Any API to configure the API method, data format, endpoint URL, request headers, attribute exclusions, record batching, and response webhooks.
All Ashby write endpoints use POST with application/json content against the base https://api.ashbyhq.com/ followed by the resource and action (for example, https://api.ashbyhq.com/candidate.create, https://api.ashbyhq.com/job.update). The Authorization header for HTTP Basic Auth and Content-Type: application/json are added automatically.
The Ashby API does not natively support batched create/update calls — each candidate, application, job, or opening is created with its own request, so record batching is best left disabled for Ashby destinations.
Important
Test payloads sent to write endpoints (such as Create Candidate, Create Application, Update Job, or Start Offer Process) will make real changes in your Ashby account. Use a dedicated test workspace or a non-production Ashby environment before sending test data against a production Ashby account.
Once all endpoint settings have been configured, click the Done button in the upper right corner of the screen to save and create the destination. To begin sending data to Ashby, open the destination resource menu, and select Activate.
The Nexset data will not be sent to Ashby until the destination is activated. Destinations can be activated immediately or at a later time, providing full control over data movement.
