Introduction
This article is part of an ongoing series that covers the Factorial HR API in depth. The focus here is a very specific operational use case: retrieving employee leave data using the Factorial HR API.
If you are building payroll systems, HR analytics pipelines, or internal reporting workflows, leave data is a non-negotiable input. This guide walks through the exact endpoints and steps required to extract that data reliably.
For a broader overview of the Factorial HR API, including authentication, rate limits, and general integration patterns—refer to the full guide available here.
Prerequisites
Before you start, ensure the following are in place:
- Access to the Factorial HR API with the required permissions
- A valid API key for authentication
- A Python environment with standard HTTP libraries such as
requestsinstalled
Without these basics, the integration will fail early.
API Endpoints
The following endpoints are used in this workflow:
- Get all employees
https://api.factorialhr.com/api/2024-10-01/resources/employees/employees - Get all leaves
https://api.factorialhr.com/api/2024-10-01/resources/timeoff/leaves
These endpoints form the backbone of employee-to-leave data mapping.
Step-by-Step Process
1. Fetch All Employees
Start by pulling the complete employee list. This gives you the employee IDs required to associate leave records accurately.
import requests
url = 'https://api.factorialhr.com/api/2024-10-01/resources/employees/employees'
headers = {
'accept': 'application/json',
'Authorization': 'Bearer YOUR_API_KEY'
}
response = requests.get(url, headers=headers)
employees = response.json()This step is foundational. Skipping it often leads to mismatched or incomplete leave data downstream.
2. Fetch Leaves for All Employees
Once employees are available, fetch leave records across the organization.
url = 'https://api.factorialhr.com/api/2024-10-01/resources/timeoff/leaves'
params = {
'include_leave_type': 'true',
'include_duration': 'true'
}
response = requests.get(url, headers=headers, params=params)
leaves = response.json()Including leave types and durations upfront avoids additional enrichment calls later.
3. Fetch Leaves for a Specific Employee
If your use case requires employee-level queries, filter leaves using the employee ID.
employee_id = 1 # Replace with the actual employee ID
params['employee_ids[]'] = employee_id
response = requests.get(url, headers=headers, params=params)
employee_leaves = response.json()This is particularly useful for employee dashboards, manager approvals, or audit workflows.
Common Pitfalls to Avoid
Most integration failures are operational, not technical. Watch out for the following:
- Using an incorrect or outdated API version in the request URL
- Missing or malformed authentication headers
- Improperly structured query parameters, especially array-based filters
- Ignoring API rate limits and retry strategies
- Failing to handle error responses and HTTP status codes
- Assuming every employee will have associated leave data
- Not validating empty or null responses before processing
Addressing these early will save hours of debugging later.
FAQs
1. What is the base URL for the Factorial HR API?
The base URL is https://api.factorialhr.com/api/2024-10-01.
2. How do I authenticate API requests?
Authentication is handled using an API key passed in the request headers as a Bearer token.
3. Can employees be filtered by location?
Yes. Use the location_ids[] query parameter when fetching employees.
4. How can I retrieve only active employees?
Set only_active=true in the query parameters for the employee endpoint.
5. Is it possible to retrieve leave types along with leave records?
Yes. Set include_leave_type=true when calling the leaves endpoint.
6. Can pending leave requests be included in the response?
Yes. Use include_pending=true in the query parameters.
7. How do I filter leave data by date range?
Use the from and to query parameters in YYYY-MM-DD format.
Knit for Factorial HR API Integration
Directly integrating with the Factorial HR API works, but it comes with long-term maintenance overhead.
Knit simplifies this by acting as a single integration layer. You integrate once, and Knit handles authentication, authorization, version changes, and ongoing maintenance for the Factorial HR API. This reduces engineering effort, minimizes breakages, and accelerates time-to-value for HR data workflows.
If scale, reliability, and speed matter, this approach is materially more efficient.




