API version 1.4
Lithuanian eID login and qualified signing, as an API
Add Lithuanian eID authentication and qualified electronic signatures (QES) to your product, built on the card itself: ATK by physical reader or NFC phone tap. For hosted remote-method ceremonies, see the Tvarka Sign API.
Native NFC card-tap
The resident taps their eID to an Android phone - no reader, no desktop install. The desktop reader path uses the same Web-eID transport gateways already speak.
Card-native, two transports
Offer physical ATK and ATK over NFC through one request and result model. Each provider enables only the methods it needs.
Pay-per-use signing
Successful ATK and service operations cost €0.07, excluding VAT. There are no subscriptions, minimums or fractional-cent adjustments.
How it works
ATK card ceremonies use the provider backend plus a card-driving client:
POST /v1/{auth|sign}/{id}/certificate (client reads the card certificate)
... the card signs the audience-bound challenge, after PIN, on the device ...
POST /v1/{auth|sign}/{id}/complete (raw signature -> verified identity or signed container)
You verify the result yourself: re-derive the challenge from your own audience and the returned nonce, and check the signature against the card certificate. You do not have to trust Tvarka's word. Signing adds PAdES, ASiC-E and ADOC assembly, a qualified timestamp, and an advisory validation axis.
The API is deliberately card-only: no Smart-ID or Mobile-ID passthrough. When you want Tvarka to run a hosted signing ceremony with remote methods, delivery and reminders, use the Tvarka Sign developer API instead.
Start building
1. Get a sandbox key
Request access. A locked, zero-rated sandbox provider is issued after a short review.
2. Run the quickstart
Create an audience-bound request, inspect the response, and continue with a source SDK or Postman. Start in five minutes.
3. Choose an integration asset
Use the Python or web SDK, import the auth or signing collection, and download the test document.
Public developer resources
Canonical OpenAPI 3.1
A single, channel-ready contract in JSON or YAML, plus an APIs.json 0.19 catalog in JSON or YAML. Specialist auth and signing contracts remain available.
Reference and examples
Rendered complete reference, specialist authentication and signing views, response examples, the complete error catalog, and a same-origin Try API console.
Commercial and lifecycle terms
Read pricing mechanics, compatibility and retention/lifecycle policy before production onboarding.
Verification keys
JWKS - public keys for independently verifying the optional identity assertion JWT. The raw certificate and signature are also returned so you can verify the audience-bound result without relying on the JWT.