How to Export Data from Keka: Methods, API Limits & Portability

How to Export Data from Keka: Methods, API Limits & Portability

Like MYNDHRX, Keka is a cloud-based HRIS and payroll platform built primarily for the Indian mid-market, with expanding operations in the US and Singapore. Its data model spans employees, departments, groups, attendance, leave, payroll, performance reviews, expenses, assets, documents, recruitment (Keka Hire), PSA (timesheets/projects), and helpdesk — each with different export paths and varying levels of API coverage.

When you need to move data out of Keka for a migration to Workday, Darwinbox, or BambooHR, or to sync into a data warehouse, teams quickly discover—much like when exporting data from CharlieHR—that HR data extraction is not a simple download. HR data is deeply relational: an employee record ties to a pay group, which ties to a legal entity, which ties to a localized tax structure. Extracting this data means untangling those relationships across multiple export surfaces.

This guide covers every realistic extraction method, the exact API constraints you'll hit, and the gaps that will force you into workarounds.

Extraction Method Decision Tree

Before diving into individual methods, use this framework to determine your extraction approach based on org size, data scope, and history requirements:

Key thresholds that determine complexity:

• Document extraction: At 50 req/min, 1 request per employee = ~1 minute per 50 employees. 2,000 employees = 40 minutes; 5,000 employees = ~100 minutes, just for documents.
• Time-series backfill: Each year of attendance or leave history requires ~5 API calls per employee (rolling 90-day windows). For 2,000 employees, one year of attendance = 10,000 requests = ~3.3 hours at rate limit.
• Module coverage: Each additional active module (Payroll, Hire, PSA, Helpdesk) roughly doubles the number of distinct endpoint families you must call.

Keka's Data Model: What You're Actually Exporting

Before choosing an extraction method, map what you need against what Keka exposes.

Method 1: UI Reports — The Fastest Path for Structured Exports

Keka's reporting engine is the most accessible export path for admins who don't write code. Reports export as Excel files; analytics graphs can also export as PNG or PDF.

How to Download the All Employees Report

Go to Org > Dashboard on the Keka portal. Click Employee Reports. Under the Employee Info section, select All Employees. Apply filters such as Business Unit, Department, Location, Cost Center, and Band, then click Run. Click the Download Icon to export as Excel.

Employee Master Details Report

For a richer dataset covering personal and professional details plus contact information, use the Employee Master Details report. Navigate to Org > Dashboard > Employee Reports and search for "Employee Master Details." Once generated, click the Download button to export as Excel.

Other Key Reports Available for Export

• Attendance status report — exportable from Time Attend > Reports
• Leave balance and accrual reports — exportable from the Leave section
• Payroll reports — Financial Information, Component Claim, Monthly Cost, Salary Revision, Employee Payroll Status, FnF reports
• Performance rating reports — Download Excel to export complete report; filter by employee, department, or location
• Performance bands report — Export as PDF via the Download icon
• Project work hours (PSA) — Export in Excel format
• Candidate reports (Hire) — downloadable from Hire > Reports
• Payslip bulk download — available from Payroll > Run Payroll > Manage Payslip, but only for finalized payroll months
• Analytics graphs — export in PNG, PDF, or Excel via export icons

Custom Reports

Keka's report builder supports drag-and-drop column selection, conditional filters, and data aggregation across modules (HRIS, Perform, Hire). Custom reports can also be scheduled for recurring delivery via SFTP — covered in Method 4.

UI Export Limitations

• Reports are filter-dependent — the Employee Master Details report requires Business Unit; running org-wide requires multiple passes
• No attachments: PAN cards, Aadhar cards, resumes, and signed offer letters are not exportable via reports
• No org configuration: Policies, approval chains, and shift rules have no export path in any direction
• Export formats limited to Excel and PDF — no native CSV or JSON output
• Flat structure: Compensation history exported via Excel often produces duplicate rows or missing historical context, complicating import into target systems with structured compensation modules
• Documents must be downloaded individually per employee from the UI
• Large orgs (5,000+ employees) may experience slow report generation or timeouts — test with filtered subsets first

Method 2: Bulk Import Templates as a Backdoor Export

Keka's Data Import feature is designed for bulk updates, but the Excel templates it generates pre-populate with your existing employee data. This makes them a useful — if unconventional — export mechanism for structured job-level data.

Navigate to Global Settings > Data Import > Employee Job Details > Import New Data, then download the template. You can choose to download for all employees or a filtered group.

Only Global Administrators can access this feature.

Available templates that pre-populate with existing data:

• Employee Job Details — legal entity, business unit, job title, department, location, reporting manager, policies, shift timings
• Employee Address — permanent and current addresses
• Employee Documents — bulk zip structure for upload/download

Limitations of the Template Approach

• Templates are designed for import, not export — column structure may not match what your target system expects, requiring transformation
• You can only update or add data; this process does not delete existing records, so templates reflect current state only (no history)
• Only available to Global Administrators
• Doesn't cover salary, attendance, leave, or performance data
• No automation — requires manual download each time; not suitable for recurring syncs

Method 3: Keka REST API — Programmatic Extraction

The REST API is the only path to automated, repeatable data extraction from Keka. It covers employee records, attendance, leave, payroll, expense management, performance, recruitment, PSA, helpdesk, background verification, and rewards.

Authentication

Keka uses OAuth 2.0 with a custom grant type (kekaapi). To obtain an access token:

curl -X POST https://login.keka.com/connect/token \
  -H "Content-Type: application/x-www-form-urlencoded" \
  -d "grant_type=kekaapi" \
  -d "client_id=YOUR_CLIENT_ID" \
  -d "client_secret=YOUR_CLIENT_SECRET" \
  -d "scope=kekaapi" \
  -d "apikey=YOUR_API_KEY"

The response returns an access_token that expires in 3600 seconds (1 hour). To obtain a refresh token — avoiding full re-authentication every hour — include offline_access in the scope parameter: scope=kekaapi openid profile offline_access. Without this, your extraction script must handle token renewal by repeating the full auth flow.

Environment endpoints:

• Production: https://login.keka.com/connect/token
• Sandbox: https://login.kekademo.com/connect/token

Rate Limits

Keka enforces a limit of 50 requests per minute, refilled in 60-second intervals. Exceeding this returns HTTP 429 with reason rateLimitExceeded. The Retry-After header specifies how many seconds to wait.

Practical throughput calculations:

At 50 req/min, a complete extraction for a mid-sized org is measured in hours, not minutes. Factor this into migration timelines.

Pagination and Time-Window Caps

Most list endpoints use offset-based pagination with a default page size of 100 records and a maximum of 200 per request:

GET /api/v1/hris/employees?pageNumber=1&pageSize=200

Pagination termination signal: an empty data array in the response indicates you've reached the last page. There is no totalCount field on all endpoints — test your specific endpoint to confirm termination behavior.

Time-window constraints are the most operationally significant API limitation:

For historical backfills, you must iterate through rolling 90-day date windows across the full date range. A 3-year history requires at least 13 sequential API calls per data type before accounting for pagination within each window.

Use the lastModified parameter (UTC format) for delta syncs — this filters to records changed since a given timestamp, avoiding full re-extraction on every run.

API Error Codes Reference

Key API Endpoints for Export

The Employee API Does Not Return Salary Data

This is the single most common discovery for teams building Keka extractions. The Employee API endpoint (/api/v1/hris/employees) returns a structurally complete-looking employee record — personal details, job data, group affiliations, custom fields, education, relationships, exit records — with zero compensation information.

To retrieve salary data, you must call the payroll-specific endpoints separately: /api/v1/payroll/salaries and the pay register endpoint. The salaries endpoint defaults to working employees only — you must explicitly include relieved employees to capture complete payroll history.

The separation is by design, not an oversight. Keka's developer documentation explicitly states that the Employee API provides comprehensive employee data "without exposing any salary or compensation information."

Sparse Fieldsets

Use sparse fieldsets (fields [employees]) to reduce response payload size when you only need a subset of employee attributes. On large orgs, full payloads add significant latency and bandwidth. Example:

GET /api/v1/hris/employees?fields[employees]=id,firstName,lastName,email,departmentId

One additional constraint: the searchKey filter on the employee endpoint requires at least 3 characters — single or two-character searches return a 400 error.

Attendance API: A Separate Key

The attendance ingestion API (for pushing data from biometric devices into Keka) uses a different authentication key from the standard API. The standard API key does not work for this endpoint. Setup requires contacting your assigned Keka Customer Success Manager or Keka Support to provision the key.

This endpoint is primarily designed for pushing attendance data in — not for extracting it. For attendance data extraction, use the standard API's attendance endpoints or the UI reports.

Sandbox Environment

Keka provides a sandbox environment at https://login.kekademo.com/connect/token that mirrors the production API surface. Always validate your extraction scripts against the sandbox before running against production. The sandbox is accessible through the Keka developer portal and uses separate credentials.

Code Example: Paginated Extraction with Rate Limiting

import requests
import time
 
ACCESS_TOKEN = "your_access_token"
BASE_URL = "https://api.keka.com/api/v1"
HEADERS = {
    "Authorization": f"Bearer {ACCESS_TOKEN}",
    "Accept": "application/json",
    "User-Agent": "Mozilla"  # Keka-documented compatibility workaround
}
 
def get_keka_employees():
    employees = []
    page_number = 1
    page_size = 200  # Max allowed
 
    while True:
        url = f"{BASE_URL}/hris/employees?pageNumber={page_number}&pageSize={page_size}"
        response = requests.get(url, headers=HEADERS)
 
        if response.status_code == 429:
            retry_after = int(response.headers.get("Retry-After", 60))
            print(f"Rate limit hit. Sleeping for {retry_after}s...")
            time.sleep(retry_after)
            continue
 
        response.raise_for_status()
        data = response.json()
 
        page_data = data.get('data', [])
        if not page_data:  # Empty array = last page
            break
 
        employees.extend(page_data)
        page_number += 1
 
    return employees
 
all_employees = get_keka_employees()
print(f"Extracted {len(all_employees)} employees.")

Note: The User-Agent: Mozilla header is a Keka-documented compatibility tip for certain client library configurations, not a general HTTP requirement. Include it if you encounter unexpected request failures. (developers.keka.com)

For time-series data (attendance, leave requests), add date chunking to stay within the 90-day window cap:

from datetime import datetime, timedelta
 
def rolling_windows(start_date, end_date, days=90):
    """Generate non-overlapping date windows of up to `days` duration."""
    current = start_date
    while current < end_date:
        window_end = min(current + timedelta(days=days), end_date)
        yield current.strftime("%Y-%m-%d"), window_end.strftime("%Y-%m-%d")
        current = window_end
 
def get_attendance_history(start_date, end_date):
    """
    Extract attendance records across a date range exceeding 90 days.
    Requires multiple API calls due to Keka's 90-day window cap.
    """
    all_records = []
    for window_start, window_end in rolling_windows(start_date, end_date, days=90):
        page = 1
        while True:
            response = requests.get(
                f"{BASE_URL}/time/attendance",
                headers=HEADERS,
                params={
                    "from": window_start,
                    "to": window_end,
                    "pageNumber": page,
                    "pageSize": 200,
                }
            )
            if response.status_code == 429:
                time.sleep(60)
                continue
            if response.status_code == 400:
                # Check: date range > 90 days, or other param error
                print(f"Bad request for window {window_start}–{window_end}: {response.text}")
                break
            response.raise_for_status()
            data = response.json().get('data', [])
            if not data:
                break
            all_records.extend(data)
            page += 1
    return all_records

Method 4: SFTP-Scheduled Reports

Keka supports scheduling reports for automated delivery via SFTP. This is the closest Keka offers to an automated bulk export without custom API code. Configure scheduling in the custom report builder — look for the SFTP delivery option after building your report.

Appropriate for: recurring feeds to a data warehouse or target system where the data types are covered by Keka's built-in reports and the latency of scheduled delivery (typically daily) is acceptable. Not suitable for real-time sync or data types that require API-only access (documents, archived candidates, multi-year time-series).

Method 5: Third-Party Tools and Connectors

An unofficial Chrome extension (by Zoomcorder) called "Export Keka Employees" generates CSV files from the Keka dashboard with a single click. Caveats before using:

• Not maintained by Keka — will break on any UI update, with no support path
• Requires granting a third-party extension access to your HRIS session
• Covers employee directory data only — no payroll, leave, or performance
• No audit trail or compliance guarantees
• Not suitable for production migration use

Unified API platforms like Apideck and Knit offer Keka connectors that normalize data into standardized HRIS schemas, abstracting pagination and rate limiting. The tradeoffs: an added vendor dependency, per-API-call cost, and a normalized schema that may not preserve Keka-specific fields (custom fields, policy assignments, group types) that matter for a complete migration.

The main integration challenges these platforms also face: managing OAuth credentials across multiple customer accounts, the 50 req/min rate limit for high-volume syncs, handling module-dependent data availability, and mapping Keka's GUID-based data model to target system schemas.

What You Cannot Export from Keka

Some data categories have no export path — not via UI, API, or template. These must be manually recreated in your target system:

• Org configuration — leave policies, approval workflows, shift rules, leave plan rules, weekly-off policies, holiday calendars
• Notification templates — email and push notification configurations
• Integration settings — connected app configurations and credentials
• Audit logs — no bulk export of system activity logs
• Handbook / knowledge base content — if configured via Keka Learn, export options are limited

Recommended Keka Extraction Sequence

A systematic sequence for complete extraction — ordered to minimize rework:

1. Inventory your active modules. Confirm which Keka modules (HRIS, Payroll, Perform, Hire, PSA, Helpdesk, Assets, Expenses) are active. API access and report availability mirror your subscription. A 403 response on a payroll endpoint means the module is not subscribed, not that your credentials are wrong.

2. Pull UI reports first. Download All Employees, Employee Master Details (per business unit), attendance, leave, payroll, and performance reports as Excel files. These serve as your baseline dataset and validation benchmark for API outputs.

3. Set up API credentials early. Register in the Keka developer portal, obtain client_id, client_secret, and api_key. Store credentials immediately — they are shown only once. Test against the sandbox endpoint before touching production. Five active keys maximum per org.

4. Extract reference data before transaction data. Pull departments, locations, job titles, groups, group types, pay groups, salary components, salary structures, leave plans, holiday calendars, and weekly-off policies first. These are your lookup tables. When you extract employees, Keka returns departmentId GUIDs, not department names — you need this foundation data to resolve foreign key references. Attempting to import employees into a target system without resolved references causes bulk import failures.

5. Extract primary records in completeness mode.

• Employees: include both Working and Relieved status
• Salaries: explicitly include relieved employees
• Candidates: run one pass for active, one with isArchived=true
• Attendance, leave requests, timesheets: iterate through rolling 90-day windows for full history
• Enforce 50 req/min throughout; implement exponential backoff on 429 responses

6. Handle documents and files separately. Use the per-employee documents API endpoint. Bulk-download finalized payslips from the UI (Payroll > Run Payroll > Manage Payslip). Fetch candidate resumes via the Hire API. Record exports and file exports are separate streams — a complete employee record export does not include file binaries.

7. Cross-validate. Compare API output counts against UI report counts. Watch for discrepancies in: total employee counts (working vs. all), date formats (Keka uses UTC; target systems may expect local time or ISO 8601), custom field mappings, and salary record completeness. Discrepancies here are cheaper to resolve before import than after.

8. Run a delta pass before cutover. Use lastModified (UTC) wherever the endpoint supports it to capture changes between your base pull and go-live. For tighter continuity on high-velocity data, use Keka's event-trigger webhooks to capture real-time changes during the cutover window.

9. Document non-exportable configuration manually. Screenshot or transcribe all leave policies, attendance rules, approval chains, shift configurations, and payroll settings. These must be recreated in the target system from documentation, not from exports.

Common Pitfalls When Exporting from Keka

Assuming the Employee API includes salary data. It doesn't. The Employee API (/api/v1/hris/employees) returns a structurally complete-looking record with zero compensation information. Salary requires separate payroll endpoint calls. This is the most common mid-project discovery in Keka migration work.

Ignoring module dependencies. If your subscription doesn't include the Payroll module, payroll endpoints return empty results or 403 errors — not a descriptive explanation. Confirm module access before building extraction scripts; don't assume subscription scope from what you see in the UI.

Using the wrong API key for attendance ingestion. The attendance ingestion endpoint requires a key provisioned by Keka Support — the standard API key does not work. For attendance data extraction, use the standard API attendance endpoints or UI reports. The ingestion key is a separate credential for a separate use case.

Underestimating rate-limit impact on large orgs. At 50 req/min with per-employee document calls, 5,000 employees takes ~100 minutes for documents alone. Multi-year time-series extraction for the same org can take 8+ hours. Build this into your migration timeline; don't schedule cutover the day after extraction begins.

Overlooking default filters that hide historical data.

• Salaries endpoint: defaults to working employees only
• Candidates: defaults to isArchived=false (active only)
• Leave requests: defaults to last 30 days
• Payslip bulk download: only works for finalized payroll months A "complete" export built without overriding these defaults will have systematic gaps.

Not handling mid-cycle compensation changes. If an employee was promoted mid-month, Keka generates two compensation records for that month covering the prorated periods. Your extraction may yield two salary records for the same employee in the same pay period. Target systems must be configured to accept mid-cycle changes, or imports fail with duplicate-period errors.

GUID translation failures breaking relational integrity. Keka returns departmentId, locationId, managerId as GUIDs. Without a maintained mapping table from Keka GUIDs to target system IDs, relational links — manager-to-report hierarchies, department assignments, pay group memberships — break silently on import. You'll import data that looks correct but has no internal relationships.

Date format and timezone mismatches. Keka stores and returns timestamps in UTC. Target systems may expect local time (IST, SGT) or a specific ISO 8601 format. Handle timezone conversion in your extraction pipeline, before import — retrofitting timezone conversions after the fact in a populated target system is significantly more difficult.

Data security and compliance. Keka holds PII and financial data — PAN numbers, Aadhaar references, bank details, salary histories. Extractions to staging servers or flat files must comply with India's Digital Personal Data Protection (DPDP) Act (enacted August 2023) or GDPR for EU-resident employees. Never transmit payroll CSV exports via unencrypted email. Encrypt at rest and in transit; restrict staging access; delete extraction artifacts after successful import validation.

Migration vs. Ongoing Sync

Migration (one-time full extraction): UI reports serve as your primary data source; the API fills gaps and enables validation. The extraction sequence above applies directly. The operational challenge is completeness — ensuring no data category is missed across all active modules.

Ongoing sync (Keka → data warehouse or ERP): The API's lastModified filter becomes essential for efficient delta pulls. Keka provides the endpoints; you own the scheduling, error handling, retry logic, and schema evolution management. Keka's attendance-source enums (Device, Web, Mobile, API, Import, Slack, Kiosk) are worth preserving in downstream systems if you need to track punch provenance for audit or compliance purposes.

Keka does not provide a native change data capture (CDC) stream. For real-time or near-real-time sync requirements, webhooks are the closest available mechanism.

When the Built-in Exports Aren't Enough

Keka's built-in exports reliably handle: a current employee snapshot, a standard payroll report pack, and a one-time audit export. Complexity increases in these specific scenarios:

• Full payroll history spanning multiple financial years with prorated mid-period changes
• Attendance logs reconciled with leave and shift data requiring multi-year 90-day window iteration
• Performance review history across multiple cycles with goal-to-review linkages
• Document extraction for all employees with metadata preservation (document type, upload date, owner)
• Custom field mappings from Keka's schema to a target system with a different field taxonomy
• Referential integrity maintained across all extracted domains (employees, departments, managers, pay groups, policies)

Each of these is technically achievable within Keka's API constraints. The operational variable is engineering time — debugging pagination edge cases, handling the salary/employee API split discovery, iterating through 90-day date windows for multi-year history, and building GUID mapping tables for all cross-references.

ClonePartner handles HRIS migrations involving Keka's specific data model — including the salary endpoint separation, UUID-based references, 50 req/min throttle, and 90-day window constraints. If you're planning a migration, we can scope the extraction effort based on your employee count, module footprint, and history requirements.