How to integrate an eIDV API into your IS: 2026 technical guide

The modern architecture of an API (application programming interface) eIDV integration rests on four technical building blocks well mastered by the platform teams of banks and fintechs.

REST/JSON (the web exchange protocol and structured data format) has become the default exchange layer between a bank's information system and its eIDV provider. 2026 recommendations:

• Explicit versioning via URL (/api/v1/verifications) or header (Accept: application/vnd.eidv.v1+json)
• JSON:API format to standardize requests and responses
• Normalized HTTP codes (200/201 for success, 4xx for client errors, 5xx for server errors)
• Idempotency on create operations (Idempotency-Key header)

Target p95 latency: below 200 ms for a synchronous call, below 100 ms for a webhook call.

Webhooks (notifications pushed by the provider) are preferable to polling, to minimize latency and avoid API quotas. Good practices:

• Immediate validation of the signature (HMAC-SHA256) on receipt
• Immediate HTTP 200 response, asynchronous business processing (internal queue)
• Idempotency mandatory: the provider may redeliver if no 200 is returned
• Exponential retry mechanism with back-off (1s, 5s, 30s, 5min, 1h, 6h)
• Time-stamped log of every event received (DORA audit trail)

The JWT (JSON Web Token — a signed token enabling server-side stateless authentication) has become the norm for stateless authentication between services. Recommended configuration:

• Signature verification via JWKS (JSON Web Key Set — the public key set published by the issuer) with short caching (5 min)
• Signing algorithms RS256 or ES256 (never HS256 for inter-organization flows)
• Short lifetime (5 to 15 minutes) with a separate refresh token
• Audience and issuer validated on every call

For sensitive eIDV flows (especially the eIDAS high level), mTLS (Mutual TLS — mutual authentication via certificates on both sides) adds a security layer: the API server requires the client to present a valid certificate. Configuration:

• X.509 certificates issued by a shared trust anchor
• Automated renewal 30 days before expiry
• Revocation handled via OCSP or CRL
• TLS 1.3 minimum (TLS 1.2 tolerated only for backward compatibility)

::: callout-info In brief — the 4 building blocks of 2026 eIDV architecture

• REST/JSON: synchronous identity verification calls
• Webhooks: asynchronous result or update notifications
• JWT: stateless authentication between microservices
• mTLS: mutual security for higher-risk flows

:::

Integration follows a progressive path in two phases, sandbox then production, with guardrails at every step.

The sandbox environment validates the technical integration with no operational risk. Typical configuration:

• Isolated test accounts with representative fictional datasets
• Predictable edge cases: success, failure, expiry, rejection
• Permissive rate limits for load testing
• Versioning synchronous with production (no API drift)

Typical duration: 2 to 4 weeks to validate every verification journey, error handling, and webhook flow.

The move to production follows a controlled ramp-up:

• Canary deployment: 1% of traffic, then 10%, then 100% over 2 to 4 weeks
• Active monitoring of metrics (latency, error rate, acceptance rate)
• Rollback ready to activate in less than 5 minutes
• Communication to operational teams (CSAT, compliance)

On 2025-2026 fintech benchmarks, observed orders of magnitude:

Accelerating factors: availability of API documentation, a dedicated platform team, a public sandbox with no access request. Slowing factors: legacy core banking IS, multi-geography integration, country-specific legal constraints.

The resilience of an eIDV integration is measured by its ability to handle errors without breaking the user journey.

Any modern eIDV API exposes a normalized error envelope:

• 4xx (client error): do not retry, fix the call or notify the user
• 429 (rate limit): retry with exponential back-off
• 5xx (server error): retry with back-off, switch to fallback after 3 failures
• timeout (>30 s): treated as 5xx, switch to fallback

A poorly calibrated retry policy worsens provider outages (thundering herd effect). Recommendation: add random jitter to the back-off to smooth out the spikes.

For critical KYC systems, the multi-vendor architecture has become a DORA standard. Three patterns:

Pattern 1 — Sequential cascade: call provider A first, switch to provider B if A fails. Suited when A is clearly preferred (pricing, quality).

Pattern 2 — Routing by segment: provider A for EU customers, provider B for non-EU customers. Suited when geographic specializations differ.

Pattern 3 — Multi-source vote: parallel call to 2-3 providers, consensus if convergence, human escalation otherwise. Suited to eIDAS high level or higher-risk operations.

::: callout-info Observed latencies by pattern

• Single synchronous call: 50 to 150 ms (HTTP/3 + QUIC)
• Cascade with fallback: 200 to 400 ms (first call + switch)
• Parallel multi-source vote: 150 to 300 ms (latency of the slowest)
• With mTLS and TLS 1.3: negligible overhead (< 20 ms)

:::

Observability is not added after integration, it is integrated at development time.

Typical SLAs (Service Level Agreements — contractual service-level commitments) observed in 2025-2026 eIDV contracts:

On the client information system side, instrument at minimum:

• Latency per endpoint (p50, p95, p99) with rolling percentiles
• Error rate per code (4xx, 429, 5xx, timeout) over a 5-min window
• eIDV acceptance rate (vs rejection rate) by risk segment
• Volume (calls per minute) with alert thresholds
• Throughput (req/sec at peak) to anticipate ramp-up

Common tools: Prometheus + Grafana for metrics, OpenTelemetry for tracing, ELK or Loki for centralized logs.

Article 11 of DORA requires full traceability of critical operations. On the eIDV side:

• Identity of the agent or system that triggered the verification
• Precise timestamp (UTC, ISO 8601)
• Reference to the customer file
• Result of the verification (success, failure, assurance level reached)
• Data exchanged (hashed, with no personal content)
• eIDV provider response (anonymized where required)

Mandatory retention: 5 years minimum for AML/CFT (anti-money-laundering and counter-financing of terrorism) operations, longer in case of an ongoing procedure.

A properly built eIDV integration embeds GDPR (the EU's personal data law) from the design phase, not after.

The data exchanged between the customer and the eIDV provider transits over TLS 1.3 at minimum. If the operation includes sensitive data (biometrics, identity), an additional application-layer encryption (AES-256 on the payload) strengthens protection.

The integration must minimize the data sent to the eIDV provider: last name, first name, date of birth, official document number are generally enough to reach the eIDAS substantial level. Additional data (address, supporting documents) is transmitted only if risk scoring requires it. The eIDV provider does not store identifying data beyond the duration needed for the verification.

The data processing agreement with the eIDV provider must include the clauses of GDPR article 28:

• Explicit purposes of the processing
• Server location (EU by default, outside EU only under SCCs)
• Listed sub-processors with prior consent
• Limited processor rights (no reuse, no profiling outside the agreed purpose)
• Documented security measures (ISO 27001, SOC 2 Type II)
• Data breach notification procedure

For transfers outside the EU, the European Commission's Standard Contractual Clauses (SCCs) are mandatory. CNIL (the French data protection authority) position since the Schrems II ruling: additional impact analysis for transfers to the United States, with complementary technical measures (enhanced encryption, pseudonymization).

::: callout-info GDPR checklist for eIDV integration

• Encryption: TLS 1.3 + application-layer encryption on sensitive data
• Minimization: transmit only what the verification needs
• Article 28: complete signed processing agreement
• EU localization by default, SCCs for non-EU transfers
• Logging: 5 years minimum, traced access

:::

TLPT (Threat-Led Penetration Testing) is required by DORA for systemic entities on a triennial cadence. eIDV providers integrated into a critical KYC journey can be involved in these tests.

The financial entity commissioning the TLPT must:

• Precisely map the eIDV flows in production
• Document dependencies and the provider's role in the KYC journey
• Notify the eIDV provider ahead of the test (contractual clause)
• Coordinate test windows with the provider's platform teams

The eIDV provider must be able to take part in the TLPT without disrupting production:

• Test environment representative of production, isolated
• Dedicated incident-response team
• Documentation of simulated incident protocols
• Post-test reporting aligned with EBA format

The eIDAS level drives the depth of the test:

• Substantial level: functional tests and classic vulnerabilities (OWASP)
• High level: adversarial tests (red team), physical attack tests, biometric data manipulation tests

Our eIDV API follows the 2026 standards described above, with specifics that help your platform team accelerate integration.

• Versioned REST/JSON API with OpenAPI 3.1 documentation, public sandbox with no access request, ready-to-use Postman collection
• HMAC-SHA256 signed webhooks with native idempotency, transparent exponential retry, accessible retry log
• JWT authentication with published JWKS, mTLS available on demand for eIDAS high flows
• Multi-source by design: the convergence of 4,000 worldwide sources is intrinsically resilient, with no fallback to configure on the client side
• Premium SLA: 99.9% availability, p95 latency below 200 ms, acceptance rate above 95% on standard segments
• DORA-ready documentation: ready-to-sign article 30 contractual clauses, TLPT support, external ISO 27001 and SOC 2 Type II audit

"Everything can be forged, except real life." Our multi-source approach removes the single points of failure that complicate the integration of single-source providers. No fallback to orchestrate, no double integration, 5 million monthly verifications already served without interruption.

::: cta Ready to integrate our eIDV API? Immediate sandbox, production rollout in 4 weeks. Discuss your project :::

How long for a basic eIDV integration? 4 to 8 weeks for a basic REST + webhooks integration, 2 to 3 months for a full-stack integration with JWT and mTLS, 4 to 6 months for full DORA compliance with TLPT testing.

Should you plan for a fallback eIDV provider? The DORA position recommends a multi-vendor strategy for critical KYC flows. A multi-source-by-design approach (such as Euroleads's) removes this need without sacrificing resilience.

What p95 latency should you target for an eIDV call? Below 200 ms for a synchronous call, below 100 ms for a webhook. Beyond that, user friction on the KYC journey degrades the acceptance rate.

How do you handle GDPR compliance with an eIDV provider? A complete article 28 GDPR data processing agreement, data minimized to the strict needs of the verification, encryption at TLS 1.3 minimum, EU localization by default, and access logging retained for 5 years minimum.

Is mTLS always necessary? No. mTLS is recommended for higher-risk flows (eIDAS high level, crypto operations, complex securities operations). For most cases (eIDAS substantial level), a JWT signed in RS256/ES256 over TLS 1.3 is enough.

Integrating a modern eIDV API in 2026 is no longer a massive IT project. With a properly positioned provider, a public sandbox, up-to-date OpenAPI documentation, and a dedicated platform team, your first identity verification journeys go live in 4 to 8 weeks. Full DORA compliance takes a few additional months, but turns into a commercial asset from the very first RFP. The competition between eIDV providers is now playing out as much on integration quality as on acceptance rate: we recommend choosing a provider whose API is built for 2026, not a legacy of the 2010s REST APIs.

To go further, see our eIDV pillar, our KYC pillar, our KYC/eIDV compliance pillar for France, our KYC vs eIDV comparison and our article how to implement a KYC framework. For a direct conversation, contact our experts.