# Tvarka ATK API > One REST API for Lithuanian eID authentication and qualified electronic signing (QES). The primary > ceremonies read the Lithuanian identity card (ATK) through a physical smart-card reader or an NFC > phone tap. The API is deliberately card-only: contract 1.4.0 withdrew the short-lived Smart-ID and > Mobile-ID passthrough, and hosted remote-method ceremonies now live in the separate Tvarka Sign API > (https://sign-api.tvarka.pro), which also ships a live MCP server. Signing adds PAdES, ASiC-E and ADOC assembly, a qualified timestamp and > an advisory validation axis, plus standalone validation, timestamp and LTV/archive trust services. > eIDAS-aligned, EU-resident, pay-per-successful-operation. Operated by Tvarka (Advokato M. Kiskio kontora INVENT + Socialiniai algoritmai, UAB), Lithuania. Base URL: https://atk.tvarka.pro/v1 — contract version 1.4.0, OpenAPI 3.1.0, 22 operations. Access is credential-gated: HTTP Basic (keyId:keySecret) server-to-server behind a provider IP allow-list, plus a short-lived ES256 JWT (clientToken) minted per request for the browser/device that drives the card. Sandbox and production share the same host; the environment is a property of the issued credential and sandbox operations are never billed. This file was generated by API Evangelist from the provider's own published contract and docs, and last reconciled against the live surface on 2026-08-31. The API host does not serve an llms.txt of its own (https://atk.tvarka.pro/llms.txt returns 404); the parent company publishes one at https://tvarka.pro/llms.txt, mirrored in this repo as llms/tvarka-pro-llms.txt. ## APIs - [Tvarka ATK API](https://atk.tvarka.pro/docs/): eID authentication, qualified signing, validation, timestamping and LTV/archive over one REST contract at https://atk.tvarka.pro/v1 ## Specs - [OpenAPI 3.1 (JSON)](https://atk.tvarka.pro/openapi.json): canonical complete contract, 22 operations, served as application/vnd.oai.openapi+json;version=3.1 - [OpenAPI 3.1 (YAML)](https://atk.tvarka.pro/openapi.yaml): the same contract in YAML - [Authentication specialist contract](https://atk.tvarka.pro/openapi/auth.yaml): the 10 auth, pairing, erasure and JWKS operations - [Signing specialist contract](https://atk.tvarka.pro/openapi/sign.yaml): the 13 signing, validation, timestamp and archive operations - [APIs.json catalog](https://atk.tvarka.pro/apis.json): the provider's own APIs.json 0.19 developer catalog - [JWKS](https://atk.tvarka.pro/.well-known/atk-jwks.json): ES256 public key for verifying the optional identity assertion JWT ## Docs - [Overview](https://atk.tvarka.pro/docs/): what the API does and how the ceremonies work - [Quickstart](https://atk.tvarka.pro/docs/quickstart/): create your first audience-bound authentication request in five minutes - [Complete API reference](https://atk.tvarka.pro/docs/api/): rendered reference over the canonical contract, including the full error catalog and the webhook - [Try API console](https://atk.tvarka.pro/docs/try/): same-origin Swagger UI against /v1 - [SDKs and Postman](https://atk.tvarka.pro/docs/sdks/): Python server SDK, web/device SDK, Postman collections - [Test data](https://atk.tvarka.pro/docs/test-data/): the deterministic atk-test.pdf fixture and its SHA-256 digest - [Get access](https://atk.tvarka.pro/docs/access/): request sandbox or production credentials - [Pricing](https://atk.tvarka.pro/docs/pricing/): per-successful-operation rates and what is metered - [Lifecycle, limits and retention](https://atk.tvarka.pro/docs/lifecycle/): versioning, compatibility, release history, retention and operational defaults - [Service status](https://atk.tvarka.pro/status/): component status, 90-day incident history, Atom feed and status JSON - [Security and data protection](https://tvarka.pro/saugumas/): eIDAS/QTSP posture, EU data residency, GDPR, vulnerability reporting ## Operations Authentication ceremony — createAuthRequest, submitAuthCertificate, completeAuth, getAuthRequest, cancelAuthRequest, getAuthPairing, claimPairing, getJwks. Signing ceremony — createSignRequest, submitSignCertificate, completeSign, getSignRequest, downloadSignedDocument, cancelSignRequest, getSignPairing. Trust services — validateDocument, timestampDocument, archiveDocument, downloadServiceDocument. All three require an Idempotency-Key request header. Erasure (GDPR) — deleteAuthRequest, deleteSignRequest, bulkErasure. ## Rules an agent must follow - The provider Basic credential is server-only. Never hand keyId:keySecret to a browser, a mobile app or an agent-facing client; pass only requestId and the request-scoped clientToken. - A completed authentication is a verified national eID identity and a completed signature is a qualified electronic signature with legal effect under eIDAS. Treat createSignRequest and completeSign as consequential actions requiring human intent, not autonomous retries. - CAN and PIN entry happen on the holder's device and are out of band. The API never sees them. - Idempotency-Key is required on validateDocument, timestampDocument and archiveDocument. Reuse the same key on retry; a different payload under the same key returns 409 idempotency_conflict. - Read two axes on a sign request: status (did the ceremony finish) and validation.status (is the resulting signature qualified and valid). Validation failure never shows up on status. - Errors are {code, message, requestId, retryable} — not RFC 9457. Fall back to HTTP status semantics for any code you do not recognise. Retry only 429 (honour Retry-After), 500, 502 and 503. - Verify the result yourself: re-derive the atk-auth-v1 challenge from your own audience and the returned nonce, check the signature against the returned certificate, and verify the optional assertion JWT against the published JWKS. - Sandbox accepts synthetic material only. Never upload real documents or personal data with sandbox credentials. ## Optional - [Agent skills](https://github.com/api-evangelist/tvarka-atk-api/tree/main/skills): packaged operating instructions for the marquee flows - [Agentic access contracts](https://github.com/api-evangelist/tvarka-atk-api/blob/main/agentic-access/tvarka-atk-api-agentic-access.yml): recommended per-operation execution envelope - [Arazzo workflows](https://github.com/api-evangelist/tvarka-atk-api/tree/main/arazzo): the ceremonies as machine-readable multi-step workflows - [Tvarka company llms.txt](https://tvarka.pro/llms.txt): the parent platform (signing, accounting, due diligence), in Lithuanian ## Sibling API - [Tvarka Sign API](https://sign-api.tvarka.pro/docs): the orchestration surface — post a document and a list of signers and Tvarka runs the hosted qualified signing ceremony for each of them, with Smart-ID, Mobile-ID and LT ATK over NFC in the Tvarka Sign app. This is where the remote methods withdrawn from the ATK contract in 1.4.0 live. - [Tvarka Sign llms.txt](https://sign-api.tvarka.pro/llms.txt): provider-published, and the only llms.txt Tvarka serves on an API host — https://atk.tvarka.pro/llms.txt returns 404. - [Tvarka Sign MCP server](https://sign-api.tvarka.pro/mcp): Streamable HTTP, registry name pro.tvarka/sign, six tools. tools/list answers anonymously; tool calls need a tsk_ bearer key.