Skip to main content

Factorial 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 a Factorial location.
factorial_api.png

Factorial

Create a Factorial Destination​

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

  2. Select the Factorial connector from the list of available destination connectors. Then, select the credential that will be used to connect to the Factorial organization, and click Next; or, create a new Factorial credential for use in this flow.

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

    Factorial destinations can also be configured manually, allowing you to send data to Factorial 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 Factorial endpoints. Each template is designed specifically for the corresponding Factorial API endpoint, making destination setup easy and efficient.

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

    Creates a new employee record in your Factorial organization. Use this template to onboard employees in Factorial from an upstream HR system, an HRIS migration workflow, or any data source that produces employee records.

    • No additional path parameters are required. The Nexset data is sent as a JSON body to the Factorial Employees API endpoint using an HTTP POST request.

    • The JSON body should contain the employee fields to be created. Required and optional fields for a new employee record are documented in the Factorial Create Employee API reference. Commonly used fields include:

      • first_name: The employee's first name.
      • last_name: The employee's last name (surname).
      • email: The employee's work email address, used for login and communications.
      • birthday_on: The employee's date of birth in YYYY-MM-DD format.
      • start_date: The employee's employment start date in YYYY-MM-DD format.
    • Each record in the Nexset will be sent as a separate API call, creating one new employee per call.

    Factorial requires a valid, unique email address for each new employee. If duplicate email addresses are present in your Nexset, the API will return an error for those records. Use Nexla's data transformation capabilities to deduplicate or validate email fields before sending to this destination.

    Update Employee

    Updates an existing employee record in Factorial by its unique ID. Use this template to synchronize employee profile changes from an upstream system—such as name changes, address updates, or role changes—into Factorial.

    • Enter the numeric employee ID in the Id field. This value is required and is embedded in the API URL path. The employee ID can be obtained from the List Employees or Get Employee source endpoints.

    • The Nexset data is sent as a JSON body to the Factorial Employees API using an HTTP PUT request. Include only the fields that should be updated in the request body; fields not included in the body will retain their current values.
    • Each record in the Nexset will be sent as a separate API call, updating one employee per call.

    The Id field must match an existing employee ID in your Factorial workspace. Sending an ID that does not exist will result in a 404 error from the Factorial API. For additional details, refer to the Factorial Update Employee API reference.

    Create Leave

    Creates a new time-off (leave) request in Factorial on behalf of an employee. Use this template to submit leave requests programmatically—for example, when synchronizing approved leave from an external system into Factorial.

    • No additional path parameters are required. The Nexset data is sent as a JSON body to the Factorial Leave API using an HTTP POST request.

    • The following fields are required in the request body:

      • employee_id: The numeric ID of the employee for whom the leave is being created.
      • start_on: The start date of the leave period in YYYY-MM-DD format.
      • leave_type_id: The numeric ID of the leave type (e.g., vacation, sick leave). Leave type IDs can be obtained from the List Leave Types source endpoint.
    • Each record in the Nexset will be sent as a separate API call, creating one leave request per call.

    For additional details about optional fields (such as finish_on, half_day, and description), refer to the Factorial Create Leave API reference.

    Approve Leave

    Approves a pending time-off (leave) request in Factorial. Use this template to automate leave approvals—for example, when an upstream approval workflow or HR system signals that a leave request should be approved in Factorial.

    • No additional path parameters are required. The leave ID is passed in the JSON request body, not in the URL path.

    • The following field is required in the request body:

      • id: The numeric ID of the leave request to approve. Leave request IDs can be obtained from the List Time Off Requests source endpoint.
    • Each record in the Nexset will be sent as a separate API call, approving one leave request per call.

    Only leave requests that are in a pending state can be approved. Attempting to approve a leave that has already been approved, rejected, or cancelled will result in an error from the Factorial API. For additional details, refer to the Factorial Approve Leave API reference.

    Reject Leave

    Rejects a pending time-off (leave) request in Factorial. Use this template to automate leave rejections when an upstream workflow or HR policy determines that a leave request should not be approved.

    • No additional path parameters are required. The leave ID is passed in the JSON request body, not in the URL path.

    • The following field is required in the request body:

      • id: The numeric ID of the leave request to reject. Leave request IDs can be obtained from the List Time Off Requests source endpoint.
    • Each record in the Nexset will be sent as a separate API call, rejecting one leave request per call.

    Only leave requests in a pending state can be rejected. For additional details, refer to the Factorial Reject Leave API reference.

Configure Manually​

Factorial destinations can be manually configured to send data to any valid Factorial API endpoint.

Using manual configuration, you can also configure Nexla to automatically send the response received from the Factorial API after each call to a new Nexla webhook data source.

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 Factorial API from the Method pulldown menu. Common methods for Factorial write operations are:

    • POST: For creating new records (employees, leave requests, etc.)
    • PUT: For fully replacing an existing record
    • PATCH: For partial updates to an existing record
    • DELETE: For removing a record

Data Format​

  1. Select the format in which the Nexset data will be sent to the Factorial API from the Content Format pulldown menu. Factorial's REST API accepts JSON (application/json) for all write operations. Nexla will automatically convert the data to the selected format for each API call.

API Endpoint URL​

  1. Enter the URL of the Factorial API endpoint to which you want to send the Nexset data in the URL field. Factorial API URLs follow the pattern https://api.factorialhr.com/api/{version}/resources/{resource_path}, where {version} corresponds to the date-based API version configured in your Factorial credential. For update operations that require an employee or record ID in the URL path, append the ID at the end of the URL (for example, https://api.factorialhr.com/api/2026-04-01/resources/employees/employees/12345).

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 (e.g., header1:value1,header2:value2).

    You do not need to include the X-API-KEY authentication header—it is automatically added by Nexla from your Factorial credential configuration.

Exclude Attributes from the Call​

Optional

  • If any record attributes in the Nexset should be omitted when sending data to this Factorial destination, select the attributes from the Exclude Attributes pulldown menu.

  • 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

  1. If records should be sent to this destination in batched API calls, check the box next to Would you like to batch your records together? to enable record batching.

  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. Some algorithms require additional settings—click on an algorithm listed below to view instructions for configuring these settings.

Response Webhook​

Optional

Nexla can automatically send the response received from the Factorial 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 any additional information returned after each call, such as the newly created record ID or validation error details.

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

Sample Request Payload​

Sample request payloads containing a portion of the Nexset data that will be sent to the Factorial 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 Factorial 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 Factorial API using the current settings.

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 the configured Factorial endpoint, open the destination resource menu, and select Activate.

    The Nexset data will not be sent to Factorial until the destination is activated. Destinations can be activated immediately or at a later time, providing full control over data movement.