Strict
Real checksums, not regex theatre
IBAN mod-97, BIC structure, GTIN GS1 check digit, NPI Luhn, GLN, pharmacode and UUID are verified by algorithm — a value that looks right but fails its check digit is caught, not waved through.
⇌AdaptivMapr
Capability · Validators
Checksum-strict validation, at commit time.
Nineteen field validators run before anything is committed — from IBAN mod-97 and GTIN check digits to NPI Luhn and LOINC codes. Invalid rows are flagged with a precise code, never silently written.
POST /v1/validate-row
What you get
Built for regulated workloads
A mapping that lands the right column but writes a malformed value is still a bad import. Every field can carry a validator, and they run at commit — not as a loose regex, but as the real check: IBANs are verified mod-97, GTINs against the GS1 check digit, NPIs against Luhn. A row that fails is flagged (or skipped) with a specific code so you know exactly what broke, and it never reaches your system of record silently.
Clinical
Healthcare code systems
LOINC, ICD-10, ATC and CPT codes are validated against their format rules, so a lab result or a claim line carries a code that will actually resolve downstream.
General
The everyday checks too
regex, enum, date_range, number_range, email, phone and url cover the ordinary fields — dates in range, enums in their allowed set, contacts well-formed — under the same commit gate.
Fail loud
Flagged, never silently committed
An invalid row is flagged or skipped with a precise validator code — you always know which field failed and why. Nothing malformed slips into your system of record unnoticed.
Reference
The 19 validators
| Validator | What it checks | Example |
|---|---|---|
| regex | Custom pattern match | ^[A-Z]{2}\d{6}$ |
| enum | Value in an allowed set | active | inactive |
| date_range | Date within bounds | 1900-01-01 … today |
| number_range | Numeric within bounds | 0 … 120 |
| Well-formed address | ada@example.org | |
| phone | Valid phone format | +41 44 000 00 00 |
| url | Well-formed URL | https://example.org |
| iban | Mod-97 checksum | CH93 0076 2011 6238 5295 7 |
| bic | SWIFT/BIC structure | UBSWCHZH80A |
| uuid | RFC 4122 UUID | 9f1c…-… |
| gtin | GS1 check digit | 4006381333931 |
| pharmacode | Pharmacode checksum | 1234567 |
| fhir_reference | FHIR reference form | Patient/123 |
| loinc_code | LOINC format | 4548-4 |
| icd10_code | ICD-10 format | E11.9 |
| atc_code | ATC format | A10BA02 |
| cpt_code | CPT format | 99213 |
| npi | NPI Luhn check | 1234567893 |
| gln | GLN check digit | 7601234567890 |
SNOMED was deliberately removed — it required a SNOMED International Affiliate License and no template used it. Do not expect a snomed_code validator.
FAQ
Common questions
At commit, on the resolved value about to be written — not as an afterthought. A row that fails its field validator is flagged or skipped with a specific code, so malformed data never lands in your system of record silently.
No. Where a field has a real check algorithm we run it: IBANs are verified mod-97, GTINs against the GS1 check digit, NPIs against Luhn, GLNs against their check digit. A value that matches a loose pattern but fails its checksum is still rejected.
It was removed on purpose. SNOMED CT requires a SNOMED International Affiliate License and no template ever used it, so carrying a snomed_code validator was a compliance liability with no benefit. We don’t plan to reintroduce it.
Yes — the regex, enum, date_range and number_range validators are parameterised, so a field can enforce your own pattern, allowed set or bounds alongside the built-in checksum validators.
Ready when you are
Put validators in production — without shipping raw records.
Spin up a key in minutes. Top up a $10 prepaid wallet — every map is a few tokens.
$10 minimum to start · pay only for what you map · PHI under BAA coverage