How to Export Data from MYNDHRX: Methods, API Limits & Gaps

How to Export Data from MYNDHRX: Methods, API Limits & Gaps

MYNDHRX is an HRIS/HRMS platform built by Mynd Integrated Solutions Pvt. Ltd., a 25-year-old Indian business process outsourcing company headquartered in Gurugram, Haryana. The platform — now branded as Qandle by MYNDX — covers 40+ modules across the employee lifecycle: recruitment, onboarding, attendance, leave, payroll, performance management, documents, expenses, separation, and compliance. It serves over 1,000 businesses and 15.5 lakh+ employees, primarily in India, with deep Indian statutory compliance built in (PF, ESI, professional tax, TDS). (myndsolution.com)

When it comes time to export data — for migration, audit, compliance, or BI — MYNDHRX behaves more as a closed operating system than an open data platform. The paths out exist, but they are not well-documented, and several require direct engagement with MYND's team.

MYNDHRX vs Qandle by MYNDX: Confirm What You Are Running

This matters more than it sounds. MYND's public product map is inconsistent: the standalone MYNDHRX site is live, the MYND trust center has a separate MYNDHRX security page, the mobile apps are still branded MYNDHRX, and MYND blog content still uses that name. At the same time, MYND's main product detail route now pushes buyers toward Qandle by MYNDX. (play.google.com)

Before you export anything, confirm with your admin or account team: which tenant family you are on, which modules are licensed, and whether your reporting layer and API access are standard or customized. If you are on the managed service model (where MYND's payroll specialists run the platform for you), your direct admin access may be limited — and your MYND account team becomes the gatekeeper for data exports.

What Data Lives in MYNDHRX?

Before choosing an extraction method, map the data objects you need. MYNDHRX's data model spans these primary entities:

Different objects require different extraction methods. You cannot pull biometric punch logs through the same interface you use to export PDF payslips. The biggest portability gap is documents and PDFs — salary slips, Form 16, and Form 12BA are generated as digitally signed PDFs and distributed through the employee self-service portal. There is no documented bulk download endpoint for these files.

Method Comparison: Choosing the Right Extraction Path

Before drilling into each method, use this matrix to select the right approach for your situation:

Method 1: Built-in Reports Export (Excel/CSV)

Best for: Ad-hoc extractions, one-time migrations, non-technical HR teams.

Qandle's reporting module provides pre-built reports and a DIY custom report builder. The pre-built catalog covers employee directory and org structure, joining and exit reports, attendance and shift summaries, leave balances and approval history, salary registers, component-wise payroll, statutory deductions, reimbursements, bonuses, and incentive reporting. (qandle.com)

How it works:

1. Log in as an admin with reporting privileges.
2. Navigate to the Reports module.
3. Select a pre-built report or build a custom report with the drag-and-drop builder.
4. Apply filters (entity, department, date range, employee status).
5. Export to Excel, CSV, or PDF.

For the Employee Master, explicitly include "Separated" or "Inactive" employees — standard reports often default to active-only and will silently omit your full workforce history.

The custom report builder supports drag-and-drop report design, real-time data updates, saved templates, daily/weekly/monthly scheduling, and role-based access. This is useful for migration-specific slices like "terminated employees only," "one legal entity," or "changes since last payroll lock." (qandle.com)

Limitations:

• No single comprehensive export. You need to run separate reports for each data domain (employees, attendance, payroll, performance, etc.) and stitch them together using a shared key — typically the employee ID or UAN. We see this same fragmentation when exporting data from other regional HRIS platforms like CharlieHR.
• Filter and field constraints. Pre-built reports include a fixed set of columns. The custom report builder gives more flexibility but may not expose every field — especially internal system IDs, audit trail timestamps, or relationship keys needed for referential integrity in the target system.
• Entity-level scoping. MYNDHRX supports multi-entity configurations. You may need to run exports per entity and consolidate manually.
• No API trigger for report generation. Report downloads appear to be UI-only — there is no documented way to programmatically trigger and fetch report files.

import pandas as pd
 
def parse_myndhrx_payroll(filepath):
    df = pd.read_csv(filepath, dtype=str)
    # Never use df.iloc[:, 7] — column positions shift month to month
    # Always access by header name
    required_cols = ['Employee ID', 'Basic', 'HRA', 'PF Deduction', 'TDS']
    present_cols = [c for c in required_cols if c in df.columns]
    missing_cols = [c for c in required_cols if c not in df.columns]
    if missing_cols:
        print(f"Warning: Missing columns in {filepath}: {missing_cols}")
    return df[present_cols]

Method 2: REST API (Available but Not Publicly Documented)

Best for: Programmatic extraction, ongoing sync, integration pipelines.

MYNDHRX's parent platform supports RESTful APIs for integration. Qandle's API integration page confirms that the platform supports API-based data exchange for employee records and payroll data. The official site states that the "integration framework supports both API-based and file-based integrations." (qandle.com)

The core problem: there is no publicly accessible API reference. No Swagger/OpenAPI spec. No developer portal. No endpoint listing. No public changelog.

This means:

• You cannot self-serve API access. You must contact MYND's implementation or support team to request credentials and documentation. Request this through your named account manager, not generic support — escalate to an implementation contact if needed.
• Rate limits, pagination behavior, authentication method, and available endpoints are not publicly verifiable. In engagements where clients have obtained API access, pagination is typically offset-based and responses are JSON, but field schemas vary by client configuration.
• You must provide static IP addresses for whitelisting — MYND's security architecture blocks requests from non-whitelisted IPs.
• The scope of what the API exposes — which entities, which fields, read-only vs. read-write — is undocumented and varies by tenant configuration.

MYND's trust page lists ASP.NET Core as the backend API stack. Security controls include MFA, configurable password policy, IP restrictions, role-based access control, encryption for custom fields, and account activity auditing. Each client has a separate database with customer-defined permissions. (trust.myndsolution.com)

What the API Handles Well

Based on third-party integration evidence (Truto, client engagements), the API is most reliable for:

• Current employee profiles and status changes.
• Real-time leave balances.
• Recent attendance logs (rolling window, not full history).
• Payroll data transfer to connected internal systems.

Where the API Falls Short

• Bulk historical payroll extraction: Pulling five years of payroll history via API will likely require thousands of paginated calls with no guaranteed resumability. Plan for timeouts and implement checkpoint logic.
• Document retrieval: No documented endpoints exist for bulk downloading historical PDF payslips or tax declarations.
• Custom schema variance: API materials note that custom data, fields, and tables can be exposed — meaning two MYNDHRX tenants may have different API response shapes. A parser built for one client will likely need adjustment for another. (qandle.com)

Method 3: File-Based Integrations (SFTP / Flat File)

Best for: Scheduled bulk transfers to ERP systems, payroll processors, or data warehouses.

MYNDHRX's documentation mentions support for file-based integrations alongside API-based ones. In practice, this typically means SFTP drops of CSV or fixed-width files on a schedule — a common pattern for Indian HRMS platforms that feed data into SAP, Oracle, Tally, or banking systems for payroll disbursement.

Limitations:

• File-based integrations are typically configured by MYND's implementation team during initial setup. You likely cannot configure a new file export independently after go-live.
• The file schema, delimiter, encoding, and schedule are set per integration and may not match your target system's import format without transformation.
• These are designed for operational data flows (payroll → bank, attendance → ERP), not for full data extraction. You will not get performance reviews, recruitment records, or document metadata through a payroll SFTP feed.
• The public specification is not published — if you need CSV-on-SFTP or another flat-file handoff for migration purposes, scope it directly with MYND during pre-termination planning.

Key distinction from Method 5 (Managed Extraction): File-based integrations are recurring operational pipelines configured at implementation. Managed data extraction is a one-time offboarding data service requested from MYND support. Do not conflate them — the team that manages SFTP feeds may not be the same team that handles offboarding data requests.

Method 4: Third-Party Unified API (Truto)

Best for: SaaS platforms integrating with MYNDHRX programmatically, or teams that want normalized employee data without negotiating directly with MYND.

Truto, a unified API platform, lists MYNDHRX as a supported HRIS integration. Through this interface, you get cursor-based pagination, normalized schemas, and managed authentication.

What Truto exposes for MYNDHRX:

• Employee profiles (name, work email, phone, job title, department, location, manager, employment status, start/end dates).
• Polling for status changes (new hires, updates, terminations).
• Provider-specific pagination and rate-limit handling (abstracted from the caller).

What Truto does not expose (based on available documentation):

• Payroll data, salary components, or tax computation details.
• Attendance and leave records.
• Performance reviews and goal data.
• Documents, salary slips, or Form 16.

Method 5: Managed Data Extraction (Support Request)

If you are executing a full system migration and need years of historical data across all modules, relying solely on CSV reports and rate-limited APIs will stall your project. MYND, as an enterprise provider, can deliver offboarding data services through their support team. In practice, much like managed extractions from other closed-ecosystem platforms like Loxo, this process takes 2–4 weeks from request to delivery — a timeline consistent with enterprise BPO vendor practice, though MYND has not published a formal SLA for this service type.

What to specify in your request:

• Format: Request standard flat files (CSV) or a SQL dump. Avoid proprietary encrypted formats that require MYND tooling to read.
• Scope: Explicitly state you need all active, inactive, and deleted employee records. Unspecified requests often return active-only datasets.
• Document archive: Request a bundled archive (ZIP/TAR) of all generated PDFs (payslips, Form 16, Form 12BA) with a manifest file mapping each filename to employee ID, period, and document type. A folder of 50,000 unlabeled PDFs is operationally useless — the manifest is as important as the files themselves.
• Audit trail: If your compliance team requires a full action history export, raise it at the start of the request — whether the audit trail is exportable in bulk is not publicly documented.

If MYND support cannot provide a mapped archive of payslips, engineering teams sometimes resort to automated headless browser scripts (using Puppeteer or Playwright) to log into the portal as an admin and systematically download documents. If you choose this route:

• Throttle aggressively — target no more than 1 request per 3–5 seconds. Fast scraping will trigger security firewalls and lock the admin account.
• Validate every file. Check PDF file sizes — a valid payslip PDF is typically 30–150 KB. Files under 10 KB are likely error pages or corrupted downloads.
• Name files systematically (e.g., EMP1234_Payslip_2025_04.pdf) immediately on download, before any batch processing, to ensure clean ingestion into the target system.

Data Portability: What the Law Says

MYNDHRX is DPDP (Digital Personal Data Protection Act, 2023) compliant and operates on MYND's ISO 27001 and ISO 27701 certified infrastructure.

India's DPDP Act does not include a right to data portability. Unlike GDPR Article 20, which gives EU data subjects the explicit right to receive their personal data in a structured, commonly used, machine-readable format and to transmit it to another controller, India's DPDP Act (Section 11–14) grants rights to access, correction, erasure, and grievance redressal — but omits portability entirely. This is a deliberate legislative gap noted by Indian privacy scholars and the Parliamentary Standing Committee during drafting.

This has a direct operational consequence: you cannot invoke a legal right to compel a structured bulk export from MYNDHRX under Indian law. Data extraction scope, format, and timeline must be negotiated contractually with MYND.

If your organization has EU-based employees whose data is stored in MYNDHRX, GDPR Article 20 portability obligations may apply separately — but enforcing them against an Indian processor requires a contract-level data processing agreement (DPA) that explicitly addresses portability. Verify whether your MYND contract includes such a DPA before assuming GDPR rights are enforceable.

Edge Cases That Break Migrations

Indian Statutory Data Formats

MYNDHRX stores and generates Indian statutory compliance data — PF ECR files, ESI returns, Form 24Q, professional tax challan data, and Labour Welfare Fund calculations. These have government-mandated formats and precise historical trails that are not analogous to any field in a global HRIS.

When extracting:

1. Separate master data (UAN, ESIC number, PAN, Aadhaar) from transactional data (monthly PF deduction amounts, TDS computation breakdowns).
2. Extract effective dates for any changes in statutory status — for example, when an employee opted out of PF after crossing the ₹15,000 wage ceiling, or when a location change triggered a different professional tax slab.
3. Plan an explicit transformation layer: systems like Workday, BambooHR, or Rippling do not have native PF/ESI field concepts. You will need to either map these to custom fields or store them in a compliance archive outside the target HRIS.

Leave Accrual Histories

Most HRIS platforms calculate leave balances dynamically based on accrual policies (e.g., 1.5 days of Privilege Leave earned per completed month of service). You cannot simply export the current balance and load it as an opening balance in the new system — unless your new HRIS supports opening balance overrides, you will have incorrect future calculations from day one.

The correct approach: extract the raw leave request history (every accrual, consumption, lapse, and encashment event) and reconstruct the full ledger in a data warehouse before loading to the target. If MYNDHRX's standard reports only surface the current balance, escalate to a custom report request or API pull for the transaction-level leave ledger.

Multi-Entity Complexity

MYNDHRX supports multiple legal entities with separate policies, approval chains, statutory registrations, and payroll configurations within a single tenant. Consolidated reports may merge entity-level data in ways that lose the entity distinction — for example, combining PF registrations across entities into a single column without the entity identifier. Verify that every export includes an entity identifier field before treating consolidated reports as your migration source.

Digitally Signed Documents

Form 16 and Form 12BA are generated and digitally signed within the platform under India's Information Technology Act. These are legally valid documents. The digital signature is cryptographically bound to the original file — a re-generated version from a new system will not carry the original signature and may not be accepted as equivalent by tax authorities or employees disputing historical records.

Confirm with MYND whether bulk PDF export is available or whether individual downloads through the employee self-service portal are the only option. If the latter, factor the download volume into your extraction timeline: a workforce of 2,000 employees with five years of payslips represents approximately 120,000 individual PDF downloads.

Building the Migration Pipeline

Whether you use UI reports, the REST API, or a managed database dump, raw data from MYNDHRX will require significant transformation before it can be imported into a new system. A reliable pipeline has three stages:

Stage 1: Raw Extraction Land MYNDHRX CSVs and API responses directly into a secure cloud storage bucket (AWS S3 or Google Cloud Storage) in their original form, without alteration. This serves as your immutable audit trail and recovery point if transformation logic needs to be re-run.

Stage 2: Normalization Write Python or SQL scripts to clean and standardize the data. Key transformations for MYNDHRX output:

import pandas as pd
 
def normalize_myndhrx_dates(df, date_cols):
    """
    MYNDHRX exports dates in DD-MM-YYYY format.
    Most target HRIS systems require YYYY-MM-DD (ISO 8601).
    """
    for col in date_cols:
        if col in df.columns:
            df[col] = pd.to_datetime(df[col], format='%d-%m-%Y', errors='coerce').dt.strftime('%Y-%m-%d')
    return df
 
def strip_special_chars(df, text_cols):
    """
    Address and name fields from MYNDHRX sometimes contain
    non-standard Unicode spaces and directional marks
    that break downstream imports.
    """
    for col in text_cols:
        if col in df.columns:
            df[col] = df[col].str.encode('ascii', errors='ignore').str.decode('ascii').str.strip()
    return df

Stage 3: Target Mapping Map normalized fields to your target system's schema. This is where you translate MYNDHRX's department codes, location IDs, and statutory fields into the corresponding values required by the new HRIS. Maintain a mapping table as a versioned artifact — it becomes the authoritative reference if field-level disputes arise during UAT.

A migration-ready MYNDHRX export typically requires at least two passes: a baseline extract for mapping and integration testing, then a final delta extract for records created or modified during the project. MYNDHRX's scheduled reporting features support the second pass if configured in advance. (qandle.com)

Pre-Migration Export Checklist

1. Confirm your tenant — verify whether your deployment is MYNDHRX, Qandle by MYNDX, or a managed setup. Document active modules, custom fields, and entity structure.
2. Request API documentation from your MYND account manager. Specify that you need endpoint list, authentication method, rate limits, and pagination behavior — and request a static IP whitelist window for testing.
3. Run and download all available reports from the reporting module. Use the custom report builder to capture fields that pre-built reports miss. Run exports per entity if applicable. Explicitly include inactive and separated employees.
4. Request digitally signed PDFs (Form 16, Form 12BA, payslips) in bulk. Clarify whether MYND can deliver as a ZIP archive with a manifest file mapping filenames to employee IDs and periods.
5. Map statutory data (PF, ESI, PT, TDS) to your target system's schema. Identify fields that will not carry over natively and determine whether custom fields or an external archive will hold them.
6. Validate per-entity exports if you are a multi-entity organization. Confirm that entity identifiers are present in every exported record.
7. Confirm audit trail exportability if your compliance team requires a full action history transfer.
8. Set a data freeze date and plan a delta sync for records created between the initial extract and go-live. Configure scheduled reports in MYNDHRX to capture this window automatically.
9. Reconcile record counts — match active employees, terminated employees, departments, leave balances, pay components, and document counts between source and target before sign-off.
10. Terminate contract only after validation — MYND's data deletion policy on account termination makes this a hard requirement. There is no documented recovery option after the destruction certificate is issued.

When to Bring In Help

The big mistake is treating MYNDHRX like a one-button export problem. It is a multi-surface extraction problem: reports for structured data, self-service and document tools for files, API or integration work for repeatable syncs, and custom engineering when the standard surfaces fall short.

If your MYNDHRX instance covers multiple entities, thousands of employees, and years of payroll history — and you need a clean, validated extract that maps to a specific target schema — this is not a weekend project. The lack of public API documentation, entity-level scoping requirements, Indian statutory data complexity, and document extraction gaps make MYNDHRX extractions specialized work that combines HR domain knowledge with data engineering.