Skip to main content

Ashby Destination

Nexla's bi-directional connectors allow data to flow both to and from any location, making it simple to create a FlexFlow data flow that sends data to an Ashby destination.
ashby_api.png

Ashby

Create an Ashby Destination​

  1. Click the + icon on the Nexset that will be sent to the Ashby destination, and select the Send to Destination option from the menu.

  2. 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.

  3. In Nexla, Ashby destinations can be created using pre-built endpoint templates, which expedite destination setup for common Ashby endpoints. Each template is designed specifically for the corresponding Ashby endpoint, making destination configuration easy and efficient.
    • To configure this destination using a template, follow the instructions in Configure Using a Template.

    Ashby destinations can also be configured manually, allowing you to send data to Ashby endpoints not included in the pre-built templates or apply further customizations to exactly suit your needs.
    • To configure this destination manually, follow the instructions in Configure Manually.

Configure Using a Template​

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.

  • To configure this destination using a template, 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.

    For the full payload reference, see the Ashby create application docs.

    Update Application

    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 Configure Manually 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.

Configure Manually​

Ashby destinations can be manually configured to send data to any valid Ashby API endpoint. Manual configuration provides maximum flexibility for endpoints not covered by pre-built templates, including custom URL patterns or batch settings.

Using manual configuration, you can also configure Nexla to automatically send the response received from the Ashby API after each call to a new Nexla webhook data source. This is particularly useful for capturing IDs returned by create endpoints (such as the new candidate ID returned by Create Candidate) so they can be used in downstream Nexla flows.

API Method​

  1. To manually configure this destination, select the Advanced tab at the top of the configuration screen.

  2. Select the API method that will be used for calls to the Ashby API from the Method pulldown menu. All Ashby write endpoints use POST:

    • POST: For all standard Ashby write operations (create, update, setValues, start actions)

Data Format​

  1. Select the format in which the Nexset data will be sent to the Ashby API from the Content Format pulldown menu. The Ashby API expects application/json for all write endpoints, so JSON is the appropriate choice for every Ashby destination.

API Endpoint URL​

  1. Enter the URL of the Ashby API endpoint to which you want to send the Nexset data in the URL field. All Ashby API URLs use 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).

Request Headers​

Optional

  • If Nexla should include any additional request headers in API calls to this destination, enter the headers & corresponding values as comma-separated pairs in the Request Headers field (for example, header1:value1,header2:value2).

    You do not need to include any headers already present in the credentials. The Authorization header for HTTP Basic Auth is added automatically based on your Ashby credential, and Content-Type: application/json is added based on the selected Content Format.

Exclude Attributes from the Call​

Optional

  • If any record attributes in the Nexset should be omitted when sending data to this Ashby destination, select the attributes from the Exclude Attributes pulldown menu. This is useful for stripping internal Nexla bookkeeping fields, or for omitting upstream IDs that Ashby would reject as unknown.

  • Any number of attributes can be selected for exclusion, and all excluded attributes will be shown in the field. To remove an attribute from the list, click the X icon next to the attribute name.

Record Batching​

Optional

The Ashby API does not natively support batched create/update calls — each candidate, application, job, or opening is created with its own request. Record batching in Nexla is therefore best left disabled for Ashby destinations.

  1. To override the default and group records into a single batched payload anyway, check the box next to Would you like to batch your records together?.

  2. Enter the maximum number of records that should be batched together in a single API call in the Batch Size field. By default, this value is set to 100.

  3. Select the algorithm that will be used to group records into batches from the Grouping Algorithm pulldown menu. The sample request shown in the panel on the right will be updated to reflect the current batching settings.

Response Webhook​

Optional

Nexla can automatically send the response received from the Ashby API after each call to a new Nexla webhook data source. This option allows you to keep track of the status of each API call and downstream-process the returned IDs and resource references.

  • To enable this option, check the box next to Would you like to process the API response as a Nexla Webhook source?.

    Enabling the response webhook is particularly useful for create endpoints (such as Create Candidate or Create Application) where the response contains the newly assigned Ashby ID that downstream flows need to reference.

Sample Request Payload​

Sample request payloads containing a portion of the Nexset data that will be sent to the Ashby API endpoint based on the current settings are shown in the Sample Payload panel on the right. These samples can be referenced to ensure that the destination and request settings are correctly configured.

  • Click on a sample request payload to expand it and view the complete payload content.

  • Sample payloads are automatically updated with each setting change, making it easy to verify that changes achieve the desired effect.

Endpoint Testing (Manual Configuration)​

After all endpoint settings have been configured, Nexla can send a test payload to the Ashby API to ensure that the destination is configured correctly.

  1. To send a test payload, select the Test button at the top of the Sample Payload panel, and click on a listed sample payload to expand it.

  2. If any modifications to the sample payload are needed, make the necessary changes directly within the sample window.

  3. Click the Send Test Data button at the top of a sample payload to send the test payload to the Ashby API using the current settings.

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.

Save & Activate the Destination​

  • 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.