Employee roster CSV import API
employee_roster_v1
Import this template via API. Import an employee roster CSV with AHV/GLN/IBAN validation and multilingual header support — healthcare-tested.
30-second curl
curl -X POST https://api.adaptivmapr.com/v1/uploads \ -H "Authorization: Bearer $ADAPTIVMAPR_API_KEY" \ -F "template=employee_roster_v1" \ -F "file=@your_data.csv"
At a glance
- Pack
- Healthcare
- FHIR resource
- —
- Risk level
- low
- Fields
- 7 (2 required, 3 validated)
Why this template?
The Employee roster template is the lowest-risk template in the healthcare pack — and the most-imported overall. It is the schema you use when a clinic onboards, when a payroll system rolls over, or when an HR director hands you a Christmas-Eve XLSX. Seven fields cover the working population: first_name, last_name (both required), an AHV number checked against the Swiss social-security regex (^756.NNNN.NNNN.NN$), a GLN that runs through the GS1 mod-10 checksum, an IBAN with country-restricted mod-97 validation, a contract_type enum (permanent / fixed_term / apprentice / freelance), and a start_date parsed across DE / FR / IT date conventions. It is `low` risk because it carries no PHI — names plus pay metadata, not diagnoses. The roster is usually the first template a customer imports because it stress-tests the cascade without any compliance overhead.
AHV is the single highest-value validator in the field — most files arrive with at least one transposed digit, and the regex catches it before downstream payroll rejects the batch. The IBAN validator runs mod-97 in chunks so it works inside a Cloudflare Worker without BigInt. The contract_type enum is deliberately Swiss-shaped (apprenticeships are a first-class contract type, not a footnote).
Migration scenarios & common foreign headers
Migration scenarios for the Employee roster: clinic onboarding where an HR director hands you an XLSX, payroll system rollover at year-end, group-practice acquisitions where two rosters must be reconciled into one, and quarterly contractor refreshes for staffing agencies. Foreign headers we see weekly: "Vorname / Prénom / Nombre / Nachname / Nom / Cognome / Apellido / AHV-Nr / AVS / Sozialversicherungsnummer / GLN / Globale Standortnummer / IBAN / Compte bancaire / Konto / Vertragsart / Type de contrat / Tipo de contrato / Eintrittsdatum / Date d'entrée / Fecha de inicio". The cascade picks up every one of these via the registered hints — and because employee rosters are the highest-volume import in healthcare, the statistics layer takes over within weeks.
Schema
The canonical column set, with the type each row carries, whether it is required, the field-level validators that fire on commit, and the multilingual header hints the cascade resolves against.
| Column | Type | Required | Validators | Hints |
|---|---|---|---|---|
| first_name | string | yes | — | vorname · prenom · prénom · given name · nombre |
| last_name | string | yes | — | nachname · nom · cognome · family name · apellido · surname |
| ahv_number | string | — | regex (^756\.\d{4}\.\d{4}\.\d{2}$) | ahv · avs · sozialversicherung · social security |
| gln | string | — | gln | gln · global location number |
| iban | string | — | iban (CH, LI, DE, FR, IT) | iban · compte · konto · bank account |
| contract_type | enum | — | — | vertragsart · type de contrat · tipo de contrato |
| start_date | date | — | — | eintrittsdatum · date d'entrée · start |
How AdaptivMapr maps your headers to this template
Five layers run in order, cheapest first. Layer 1 (Statistics) auto-accepts headers that have been mapped the same way across past uploads. Layer 2 (Heuristic) compares your header to the column name, the optional label, and every registered hint (DE / FR / IT / EN / ES) after a Unicode-and-punctuation-normalising pass. Layer 3 (Fuzzy) catches typos and reordered words. Layer 4 (Semantic) uses cached embeddings to catch the long tail of paraphrases. Layer 5 (LLM) only fires on genuinely ambiguous columns, constrained to the template’s allowed column set so it cannot invent a field. When a layer auto-accepts, the lower-cost layers below it never run — that is the cost lever.
REST · POST /v1/uploads
Pass the template_id; the cascade picks up the rest.
curl -X POST https://api.adaptivmapr.com/v1/uploads \ -H "Authorization: Bearer $ADAPTIVMAPR_API_KEY" \ -F "template=employee_roster_v1" \ -F "file=@your_data.csv"
The canonical template definition is read-only at GET /v1/templates/employee_roster_v1.
MCP · Cursor / Claude Desktop
Drop AdaptivMapr into your IDE. Schema-only calls are free and unlimited.
// In Cursor or Claude Desktop with the AdaptivMapr MCP server installed:
adaptivmapr.match_headers({
template: "employee_roster_v1",
headers: ["first_name", "last_name", "ahv_number", "gln"]
})MCP install instructions →FAQ — Employee roster CSV import
Is the employee roster PHI?
No — it contains employment metadata, not health information. The template is marked `low` risk and runs in schema-only mode for free, with no DPA required.
Can I extend it for non-Swiss employees?
Yes. Fork the template and either drop the AHV field, replace it with a country-specific equivalent (German Steuer-ID, French NIR), or make it optional. The cascade and validators inherit cleanly.
Does the template handle terminated employees?
Add an optional `end_date` field by forking. The canonical version is roster-shaped (people who currently work here); historical headcount belongs in an audit table.
How does the IBAN country restriction work?
The default allow-list is CH / LI / DE / FR / IT — the cluster Swiss healthcare hires across. Cross-border employers should fork and broaden the array; the validator otherwise rejects out-of-list IBANs at import.