Integration review and access to the production environment

What is a Dokobit integration review?

It is an assessment of your integration with Dokobit services before giving you access to the production environment. It is done to ensure your integration meets our best practices and market quality standards. We will look through our logs for any discrepancies in the integration and give best-practice recommendations during the review. This is done to prevent significant issues before going live and ensure a smooth transition to the production environment.


When and where?

The review should be done once you have completed your integration in our sandbox environment. The integration review time is organised after your contract details are finalised and the contract is signed. We schedule a video conference call in which we ask you to demonstrate your integration from the user's perspective.

Once you are ready to have a review, please reach out to us at developers@dokobit.com.

We typically use Microsoft Teams for integration reviews. We highly suggest checking if screen sharing, microphone, and audio work correctly to avoid any issues during the review. This article might help you troubleshoot any potential issues. If you can not use Microsoft Teams for any reason, please let us know in advance so we can arrange an alternative method for the review.

Integration reviews can be done in English and Lithuanian.


How to prepare for the integration review?

To prepare for a successful integration review, we would highly suggest that you:

  1. Test the implemented workflow yourself (test data can be found here):
    1. Ensure the end-user can complete implemented tasks (e.g., authenticate, sign the document, add/remove the signer, etc.).
    2. Ensure the flow is logical (e.g., the end-user is correctly redirected after authentication/signing).
    3. Check if errors are handled correctly for Identity API and Documents API solutions (the error handling guide is available here).
    4. Check if localisation is being handled correctly when multiple languages are used.
    5. Timeouts and request frequencies are logical (status checks are performed efficiently, pulling stops after a timeout, error, or cancellation).
  2. Check if your integration adheres to the What You See Is What You Sign (WYSIWYS) principles:
    1. The control code is clearly displayed.
    2. The end user can cancel the transaction.
    3. The document is available for preview before signing.
  3. Mobile-ID and Smart-ID services provided by SK ID Solutions in Lithuania, Latvia, and Estonia must follow the guidelines and placement requirements for Mobile-ID and Smart-ID brand elements available at their official webpages: https://www.mobile-id.lt/en/logos-and-branding/ and https://www.smart-id.com/e-service-providers/smart-id-branding/.

Make sure to consider efficient data retrieval practices

  • Use filtering when retrieving lists of resources and utilise available query parameters to filter results effectively for managing large datasets. This approach reduces response sizes and improves performance. An example would be the GET /api/signing/list.json method. It allows filtering by signing status and signing creation from/to dates.
  • To minimise processing time, avoid unnecessary data fetching and frequent data pull requests that could accumulate over time.
  • Use request batching to minimise round-trip times and reduce connection overhead by grouping similar or related operations into batch requests. We recommend limiting batch size to 10 requests per batch to maintain consistent performance and avoid request queue congestion. Continue to the next batch only after all responses from the previous batch have been received.

Protect your integration with proper authentication and authorisation

  • Keep your API access token confidential and do not expose it in client-side code or public repositories.
  • To adhere to the principle of least privilege, use API access tokens with the minimal permissions required for your application's functionality.

Verify input validation and error handling

  • Ensure all data sent to the API is validated (where possible) on your end to prevent malformed requests.
  • Implement comprehensive error handling in your application to manage different HTTP response statuses and error messages returned by our API endpoints.

Weigh the extent of monitoring and logging required for your integration

  • Keep track of your API usage patterns to detect any unusual activity that could indicate security issues or misuse.
  • Maintain logs of API calls for auditing and debugging purposes, ensuring that sensitive information is handled in compliance with data protection regulations.

Additional features

Please see a list of features and functionality available for different API products that you might find helpful for your use case. Information about implementation can be found in our documentation, code examples and Developer guides.


Universal API

  • Internal and External signing flows can be combined. This means that you can add external participants to internal signing.
  • An additional authentication step can be enabled for external participants before they view and sign the document by providing their personal and country codes.
  • Access to documents for pending participants can be removed by removing the participant from signing or deleting the signing.
  • e-Sealing is supported.
  • API documents can be made available in the Dokobit Portal for Enterprise plan administrators.
  • Qualified validation service (limited liability) is available.
  • Branding for the production environment can be set in the API Dashboard after the access token is generated and shared with our contract managers.

Portal API

  • An additional authentication step can be enabled for accountless participants before viewing and signing the document by providing their personal and country codes. Participants with Dokobit Portal accounts are authenticated when accessing the Portal.
  • Access to documents for pending participants can be removed by removing the participant from signing or deleting the signing.
  • e-Sealing is supported.
  • API documents can be made available in the Dokobit Portal for Enterprise plan administrators.
  • Qualified validation service (limited liability) is available.
  • Branding for the production environment can be set in the API Dashboard after the access token is generated and shared with our contract managers.

Identity Gateway

  • You can host a CSS file that you manage on your end with the desired Identity Gateway UI changes for redirect based integration. Please check Identity Gateway CSS Styling.
  • You can directly customise the logo and primary colour of embedded integration through integration JS, as indicated in the documentation. More UI modifications can be overwritten with CSS using classes in https://id.dokobit.com/assets/style/identity/identity.css.
  • User data provided in the API request will be prefilled for Mobile-ID, Smart-ID and Audkenni app.

Documents Gateway

  • Documents Gateway stores uploaded files for 30 days. After this period, the document signing with all associated files will be deleted automatically. If the document lifecycle needs to be longer, you should implement a mechanism to re-upload the files and create new signings.
  • You can host a CSS file that you manage on your end with the desired Documents Gateway UI changes. Please check the Documents Gateway CSS Styling.
  • You can validate e-seals and signatures (QES and AdES) using non-qualified validation functionality.

What happens after the review?

After an efficient integration review, we will send the production environment details to the person responsible according to the signed contract. If the integration review is unsuccessful, an additional review must be organised once all outlined issues have been addressed.

A review can be performed again if configuration or other changes are planned for your integration and you feel that our consultation would be beneficial.

Still need help? Contact us Contact us