Blog · Comparison
Evaluating a Digitap face-match alternative: a drop-in contract, published accuracy and public pricing
If you are weighing alternatives to Digitap's face-match endpoint, here is an honest checklist — a Digitap-compatible request contract, a richer signed response, benchmarks with their dataset attached, a self-host option and transparent per-call pricing.
A checklist, not a takedown
Search “Digitap alternative” and the page is mostly competitor listicles and thin directories — pages with a reason to rank you somewhere on a table, not to help you decide. This is not one of those. Digitap is a capable, widely-used stack, and nothing here disparages it or claims to know its internals. What this post does is narrower and, we think, more useful: if you are already evaluating alternatives for a face-match integration, here is an honest checklist of verifiable properties to check — with our own answers, so you can hold us to them.
Everything below is a fact about our API, sourced from the integration guide, the eval harness and the pricing configuration. We compare on what we can prove, not on specifications of another vendor we cannot verify.
Check 1: is it a drop-in request contract?
The migration cost of a face-match vendor is dominated by how much of your integration you have to rewrite. Our success bodies keep a Digitap-compatible envelope, and the face-match call takes the two images you already send — person (the selfie) and card (the reference photo) — as multipart. For many integrations the change is the base URL and the auth header, not the request shape:
curl -X POST https://liveliness.neetix.in/v1/face/face-match \
-H "Authorization: Bearer $LIVELINESS_API_KEY" \
-F "person=@selfie.jpg" \
-F "card=@id_card.jpg" \
-F "clientRefId=kyc-2041"Request shape and envelope from INTEGRATION.md and the face-verification product spec. The match runs on ArcFace 512-d embeddings with calibrated cosine scoring; /v1/face/verify is an alias of the same endpoint.
Check 2: how much does one call actually tell you?
A face-match integration that returns only a score forces you to make a second call for liveness, a third for quality, a fallback for spoof. Ours folds them into one signed response: match plus liveness plus spoof, mask, apparent-age bracket, emotion, a quality vector, spectral forensics and capture-integrity signals, all documented, all in the same envelope.
{
"verdict": "approved", // approved | review | declined
"result": {
"is_same_face": true,
"same_face_confidence": 0.94,
"cosine_similarity": 0.41,
"liveness_score": 0.98,
"liveness_status": "...",
"spoof_detected": false,
"forensics": { "high_freq_ratio": ..., "spectral_peak": ... },
"face_signals": { "mask_confidence": ..., "age_bracket": "20-29",
"emotion": "..." },
"capture": { "selfie_sha256": "...", "exif_present": true,
"edited": false, "replayed": false, "signed_capture": ... }
},
"warnings": [ ... ],
"mode": "live" // or "test"
}Every response is optionally Ed25519-signed — X-Neetix-Signature over the exact bytes, public key at GET /v1/verification-key — so an auditor can prove offline that a verdict was not tampered with. Fewer follow-up calls per decision is also a pricing property, which is Check 5.
Check 3: are the accuracy numbers published, with a dataset?
“99% accurate” without a dataset and an error curve is marketing. We publish the curve. On the LFW View-2 protocol — 6,000 pairs, engine-side detect and align — the license-clean stack scored an EER of 3.05% at cosine 0.126 with zero skipped pairs, and the eval harness that produced it ships in the repository so you can re-run it on your own data.
Read the caveats — they are the point
LFW is easy, celebrity-heavy and not India-representative. It says nothing about selfie-versus-Aadhaar matching or low-light capture, and a ~3% EER is mediocre against the big research packs. We publish it with that caveat rather than rounding it to a marketing figure — an India-representative evaluation is the next accuracy work, and per our benchmarks policy it will ship with the dataset and demographic breakdown attached or not at all. The full method is in the engine write-up.
Check 4: can you self-host it?
For a bank or lender, the strongest data-residency answer is that biometric images never leave your infrastructure. The same engine runs as one pure-Rust binary on your own hardware — no onnxruntime, no libpq, no GPU, embedded migrations, air-gappable — which is a shape most cloud-only verification APIs cannot offer. The details are in the self-host write-up; the same face-verification contract runs in both places.
Check 5: is per-call pricing public?
If learning the price needs a sales call, so will learning the price increase. Ours is prepaid credits, debited per call: a face match is 2 credits, most checks are 1, and signup includes 1,000 free credits with the key shown once. The full schedule and a usage calculator are on the pricing page. One honest note: the rupee value of a credit is indicative until launch, and we say so on that page rather than printing a number we might change.
What we deliberately do not claim
The honest boundary
We do not publish Digitap’s internal specifications, thresholds or accuracy, because we cannot verify them — and a comparison built on unverifiable claims about a competitor is exactly the content this post is meant to be an antidote to. We also hold no iBeta, NIST, ISO or SOC 2 certification; our status is stated plainly on the trust page. The right way to use this is as a checklist: take these five questions to any vendor, ours included, and keep the ones whose answers you can actually verify.
To try the drop-in path yourself, the face-verification product page has the endpoints and a runnable request, the pricing page has the credit costs and free tier, and the vendor checklist carries the longer list of questions with our answers linked.