Electronic Document Management System Integration into Mobile Application
Approve contract via mobile app, sign work acceptance report on tablet right at site, send primary documents to accounting without paper. EDM integration into mobile product—not just API requests: electronic signature, cryptography, legal document significance, Russian regulatory field specifics.
EDM Ecosystem in Russia
Main operators to integrate with:
| Operator | API | FTA Accreditation | Features |
|---|---|---|---|
| Diadoc (Kontur) | REST API | Yes | Most widespread, good docs |
| SFERA Courier (SKB Kontur) | REST API | Yes | Focus on logistics docs |
| 1C-EDM | No public API | Yes | Only via 1C gateway |
| Tinkoff EDM | REST API | Yes | Newer, docs developing |
| EDO Lite (Tensor, SBIS) | REST API | Yes | SBIS ecosystem integration |
For new projects, Diadoc most popular—most complete API, large client base, good documentation at developer.diadoc.ru.
Electronic Signature: Critical Point
Legally significant EDM requires qualified electronic signature (QES) or non-qualified (NES) depending on document type. Key distinction from "just press Sign" in interface.
Mobile device signature implementation—several methods:
1. Cloud Signature (recommended for mobile). QES stored in secure operator or certification center storage. App requests signing via API—user confirms via SMS code or push notification. Private key never leaves cloud. Diadoc provides cloud signature via Kontur.Crypto.
This is the right path for mobile. Storing QES private key on mobile—legally risky and technically complex.
2. Token/Smart Card. USB token connection (Rutoken, eToken) via Lightning/USB-C adapter—exotic for mobile, but happens in industrial scenarios. Requires manufacturer SDK and MFi support.
3. Simple Electronic Signature (SES). For internal EDM (company agreement not requiring QES)—use SES, basically authorized user action logged in system. Lower legal force, sufficient for internal circulation.
Diadoc API Integration
Authorization—OAuth 2.0 with client credentials or via Kontur.ID. For mobile app, use Authorization Code Flow:
GET https://auth.kontur.ru/api/authorization/v5.7/oauth/login
?client_id={client_id}
&response_type=code
&redirect_uri=myapp://auth/callback
&scope=diadoc
After getting code, exchange for access_token. Token has limited lifetime—implement automatic refresh via refresh_token.
Get documents:
GET https://diadoc-api.kontur.ru/V3/GetDocuments
?boxId={boxId}&filterCategory=Any.Incoming
Authorization: DiadocAuth ddauth_api_client_id={client_id},ddauth_token={token}
Response—XML or JSON depending on Accept header. For mobile, JSON preferable.
Document Work on Device
PDF View. Diadoc returns documents in PDF or TIFF format (for formalized—XML). On iOS render PDF via PDFKit (built-in since iOS 11), TIFF via UIImage. Android—PdfRenderer or AndroidPdfViewer library. For XML formalized documents (Universal Transfer Document, invoice), need XSLT-template rendering—Diadoc provides print forms via API.
Signing. With cloud signature: POST /V3/PostSignatures with DocumentId and user confirmation. API returns signing status asynchronously—need polling or webhook.
Create Outgoing Document. For non-formalized: user attaches PDF/DOCX from filesystem (UIDocumentPickerViewController / ACTION_OPEN_DOCUMENT), we make POST /V3/PostMessagePatch with base64-encoded file content and metadata.
Formalized Documents (UTD, TORG-12, Acts)
Separate story. Formalized documents—XML per FTA formats (orders MMV-7-15/820@, ED-7-26/736@). Can't just attach as file—must generate XML from data per format. Diadoc provides XML generator via POST /GenerateTorg12XmlForSeller, POST /GenerateUniversalTransferDocumentXmlForSeller and similar.
On mobile, usually user doesn't create UTD from scratch—they approve or sign already-created. Formalized document creation better on web or in ERP.
Notifications on New Documents
Push on incoming document for approval—key feature for working EDM app. Diadoc supports webhooks (POST /V3/Subscriptions): on event, system POSTs to your endpoint, server sends FCM/APNs push.
Mobile processing: push click opens documents list filtered "needs action".
Offline and Caching
Cache documents locally—user can view already-loaded without internet. For sensitive data—encrypt cache via iOS Data Protection (class NSFileProtectionComplete) or Android Keystore + AES-256. Document list stored in Core Data / Room with network sync.
Implementation Process
- Requirements audit: which document types, which signature (QES/NES/SES), which EDM operator already used in company
- Signature method selection: cloud signature—only reasonable option for mobile users without corporate MDM
- Integration prototype: EDM operator test environment, basic requests
- Development: authorization, document list, viewing, signing
- Testing: legal scenarios must check with EDM operator
- Security audit: token storage, cache encryption, interception protection
Timeline depends on complexity: viewing and approval without document creation—3-4 weeks. Full cycle with creation, signing, cloud QES integration—2-3 months. Formalized documents work adds 2-4 more weeks.