Short answer

For a Lithuanian online store, courier integration means three things at once: the buyer picks a delivery method and parcel locker at checkout, the store creates a shipping label and tracking number automatically, and the warehouse or operations team books a courier pickup without retyping addresses. The carriers most shops use in Lithuania (Omniva, DPD, LP Express, Venipak) publish either an API, official e-shop modules, or both. GLS in Lithuania operates through its partner SmartPosti, so the practical connection is usually SmartPosti's modules and API, not a separate public "GLS LT developer portal". Medium and larger merchants rarely stop at a single plugin: they need multi-courier checkout, shared order status logic, and a clear choice between a carrier plugin, a shipping aggregator, or a direct API into their own system. Below is a buyer-side comparison of what each carrier officially supports, and when each integration path makes sense.

Why courier integration pays off

Once you ship tens of parcels a day, manual work costs more than a proper connection. Without integration, someone opens every order, copies the address into a carrier self-service portal, prints a label, pastes the tracking number back into the store, and books a pickup separately. Mistakes are expensive: the wrong locker ID, a reused barcode, a customer who never receives a tracking email.

Integration collapses those steps. The buyer selects a locker or home delivery, your system registers the shipment with the carrier, receives a label (PDF or Base64) and a tracking number, and can create a pickup request through the API. What remains is packing and sticking the label on the box.

This article is written for the buyer side in Lithuania: store owners, e-commerce managers and IT partners planning or reviewing logistics. For accounting connections we covered Integrating with Rivilė, Directo and Agnum. For how to budget custom work, see How much does custom software development cost.

Three paths: plugin, aggregator, direct API

Almost every Lithuanian e-shop logistics setup fits one of three models. The question is not which is "best", but who owns the business rules and who pays for maintenance.

1. Carrier plugin

Omniva, DPD, Venipak and SmartPosti ship modules for common platforms: WooCommerce, Shopify, PrestaShop, OpenCart, Magento. A plugin shows lockers at checkout and generates labels in the admin. Strength: fast go-live on a standard theme and catalogue. Weakness: several carriers mean several plugins, and a custom theme, B2B checkout, kits or split shipments quickly exceed what the module supports.

2. Shipping aggregator

An aggregator gives one admin layer across carriers (DPD's own e-shop page, for example, lists ShippyPro among ready connections). Strength: one checkout surface and one place to print labels. Weakness: another vendor, another API and pricing model, and niche services (cash on delivery, age check, custom returns) are not always available.

3. Direct API into your system

Your store, ERP or warehouse system calls each carrier's API. This is the usual path for medium and larger businesses that already have (or plan) a custom order pipeline. Strength: one multi-carrier ruleset, your own pricing and warehouse logic, a shared error log. Weakness: a contract with each carrier, a test environment, and ongoing work when carriers change fields or locker formats.

A common mix: multi-carrier checkout in your code, labels sent straight to Omniva, DPD, LP Express or Venipak APIs. An aggregator stays as a fallback when speed matters more than control.

What a solid courier connection must do

Regardless of carrier, ask for the same capabilities. If any of them are missing, manual work returns.

Capability Why it matters
Locker and pickup-point list Checkout: the buyer picks a location; the list must refresh automatically
Shipment registration Address, weight, service code, unique shipment ID
Label (address card) PDF, Base64 or email for warehouse printing
Tracking number and statuses Customer emails, support, returns follow-up
Courier pickup booking Collection from the warehouse without a separate phone call
Error and duplicate control The same barcode or order is not submitted twice

Use this list as acceptance tests: each row can be verified with a test shipment.

Omniva: API and e-shop modules

Omniva documents business data integration on its API documentation page. Officially listed features:

  • transferring shipment information;
  • ordering an address card (label);
  • tracking shipment status and location;
  • creating and cancelling courier pickups;
  • querying parcel locker locations.

Labels can be ordered from Omniva's server (delivered by email or as Base64) or printed by you after agreeing the layout with your account manager. For B2C import, Omniva states that data is confirmed automatically and cannot be edited later: if something is wrong, you resubmit, and the same barcode must not be reused. That design constraint belongs in your validation layer before the API call.

For online stores Omniva offers modules for WooCommerce, Shopify, PrestaShop, OpenCart and Magento, plus a custom PHP library (e-shop integration). Delivery covers parcel lockers or home addresses in Estonia, Latvia and Lithuania. Omniva publicly cites a Baltic locker network of more than 1,300 locations.

Access requires an Omniva business contract; API credentials come from your account manager. Without them, neither the plugin nor the API will work in production.

DPD: plugins and the esiunta.lt API

DPD Lithuania maintains a dedicated Plugins for e-shops page. It lists OpenCart, Shopify, Magento (2.2 and 2.3), PrestaShop and WooCommerce plugins, plus ready connections on ShippyPro, eShoprent, Freeshop and VERSKIS, and OXID via partner NFQ.

DPD highlights the outcomes a connection should enable:

  • choice between home delivery and a parcel locker;
  • locker selection at checkout;
  • the option to price locker delivery lower than courier (a commercial choice, not a fixed public rate in this article);
  • delivery in Lithuania, Latvia, Estonia or elsewhere in Europe;
  • automatic updates of the locker list.

Separately, DPD documents the esiunta.lt API for its parcel labelling tool, with a downloadable guide. Continuous automatic locker-list updates need that API configured specifically; DPD points technical questions to your IT team and their support email.

Extras worth wiring into order statuses: DPD Predict (SMS with an about one-hour delivery window), live tracking, and parcel management (the recipient can change day, address or redirect to a locker). Those are customer-experience features your status model should reflect, even when they are not "API endpoints" in a narrow sense.

LP Express (Lietuvos paštas): API via self-service

Lietuvos paštas API for business is aimed at a direct link between your systems and LP EXPRESS. Officially, the API helps you:

  • send outbound shipment data faster;
  • fill declaration forms more easily;
  • obtain shipping labels (stickers);
  • call a courier;
  • check address spelling and resolve postal codes automatically;
  • follow delivery statuses in real time.

Activation after contracting is described as simple: in LP EXPRESS self-service open Integrations, start LP EXPRESS API, and use the installation docs for production and test environments. The carrier states that contracting takes no more than one working day, and that API activation (including a test mode) is a single click in self-service.

Practical caveat: detailed technical specs (endpoints, fields) live inside self-service after activation, not on the public marketing page. The first project step is the contract and test access; without them a developer has nothing to call.

Venipak: XML API and modules

Venipak offers both a direct API and e-commerce modules. Public Postman API documentation describes XML import to https://go.venipak.lt/import/send.php (or a Basic Authentication variant). The shipment XML covers consignee, sender, attributes and packs; required fields are marked in the docs. Separate attribute blocks exist for international and global shipments.

For e-commerce, Venipak lists support for WooCommerce, OpenCart and Shopify (contacts on its e-commerce page), Magento and PrestaShop (via support@mijora.lt), and a Mozello integration that uses an API user ID, password and Login ID. Modules let buyers pick a locker at checkout, generate labels and track parcels.

Venipak's help note on API changes stresses that checkout should use the display_name parameter for locker titles, while name remains for labels and SMS. That small detail is a frequent bug in custom builds: if checkout shows the technical name, buyers see the wrong label.

For returns, Venipak publicly describes calling a courier, applying a return sticker, and dropping the parcel at a locker or pickup point: useful when reverse logistics should stay on the same carrier as outbound shipping.

GLS in Lithuania: SmartPosti partner, not a standalone public GLS portal

Be precise here. On the GLS Group partners list, Lithuania is covered by SmartPosti UAB (Kaunas), website smartposti.lt. In Lithuanian e-commerce, "GLS API integration" usually means SmartPosti modules or the SmartPosti API, not a separate public gls.lt developer site.

SmartPosti publishes modules for Magento, PrestaShop, OpenCart, WooCommerce and Shopify (Download modules). You need a SmartPosti contract and API credentials. SmartPosti also publishes API documentation (PDF) for creating orders and managing delivery locations.

MyGLS API documentation that GLS publishes for some other countries is not the same interface as the Lithuanian partner stack. If a proposal says "GLS API", ask which one: SmartPosti API, MyGLS, or a third-party aggregator. Without that clarification, estimates and timelines diverge quickly.

Takeaway for buyers: the GLS brand is present in Lithuania, but public docs and plugins run through SmartPosti. Plan the connection around a SmartPosti contract and modules, not around another country's MyGLS PDF.

Side-by-side comparison

Carrier Public API / docs Officially mentioned modules Labels Locker list Courier pickup Lithuania note
Omniva Yes, business API docs WooCommerce, Shopify, PrestaShop, OpenCart, Magento, PHP lib Yes (server / Base64) Yes (API query) Yes (create / cancel) Business contract and manager credentials required
DPD esiunta.lt API + plugins page WooCommerce, Shopify, Magento, PrestaShop, OpenCart, others Yes Yes (with API config) Via DPD / plugin flow Also aggregator links (ShippyPro etc.)
LP Express Yes, via self-service after activation Plugin / API through LP EXPRESS self-service Yes (stickers) Via LP EXPRESS network Yes (courier call) Test environment in self-service
Venipak Yes (XML / Postman) WooCommerce, OpenCart, Shopify, Magento, PrestaShop, Mozello Yes Yes (display_name at checkout) Yes (modules / self-service) XML import to go.venipak.lt
GLS (via SmartPosti) SmartPosti API PDF; MyGLS is not the LT portal Magento, PrestaShop, OpenCart, WooCommerce, Shopify Yes (via SmartPosti) Yes (SmartPosti network) Yes (in modules) GLS partner in LT: SmartPosti

The table reflects public carrier pages as of October 2026. We do not quote prices, SLAs or exact endpoint lists here: those depend on contracts and are often not public.

Multi-courier checkout: buyer and system view

A mid-size Lithuanian store rarely stays on one carrier. Buyers in different cities prefer different lockers, and some parcels (bulky, COD, B2B) only work with a courier.

In the system, multi-courier means:

  1. At checkout, several delivery methods with clear names and prices you set from your contracts.
  2. Locker selection per carrier: an Omniva map is not used for a Venipak shipment.
  3. On the order, you store carrier code, service type, locker ID and later the tracking number.
  4. Label printing in the warehouse filters by carrier: one action for today's Omniva batch, another for DPD.
  5. Tracking emails use the correct carrier tracking URL.

The usual failure mode is several plugins without shared status logic. An order shows as Complete in WooCommerce while the label was never created, and support does not know which self-service to open. A thin custom orchestration layer (or a well-configured aggregator) removes that confusion.

Returns and the contract-withdrawal button

Logistics does not end when the label prints. Returns need a reverse path: return label, pickup from the customer or drop-off at a locker, status updates in the store, and restocking or supplier return when needed.

Since 19 June 2026, Lithuanian distance-selling businesses must provide an on-site way to withdraw from a distance contract. VVTAT reminds merchants that the website or app must offer a clearly findable function (a withdrawal button or equivalent) so the consumer can submit the request electronically, and that receipt must be confirmed without delay on a durable medium (for example email). This is not a new 14-day withdrawal right; it is a requirement that the existing right is easy to use in the same interface where the purchase was made.

In courier terms: the withdrawal flow should connect to return logistics (when to generate a return label, when to wait for the goods, when to refund). Keep the legal function and the label API on the same order screen so support does not work across three tools.

How to choose a path for your business

Situation Likely path
WooCommerce / Shopify, one carrier, standard theme Official carrier plugin
2-4 carriers, packaged platform, little custom logic Several plugins or an aggregator
Custom store or ERP, warehouse rules, multiple warehouses Direct APIs into your system
"GLS API" appears in a quote Clarify: SmartPosti contract and modules / API
Docs only after contracting Contract and test access first, then the estimate

If you are also connecting carriers to accounting and warehouse systems, start with a data map: which system is the source of truth for the order, the label number and the return status. The method is the same as for other integrations and automation work.

What to do next

  1. Collect your current carrier contracts and ask each account manager for API or module access, including a test environment.
  2. Write down which delivery methods you want at checkout next quarter (not every option on day one).
  3. Decide whether labels are printed from the store admin or from a warehouse / ERP screen.
  4. Put into acceptance tests: locker selection, label PDF, tracking number, pickup booking, and one deliberately invalid address.

DESAmedia can design a multi-courier layer, connect carrier APIs to your order system and keep an error log under watch. See Integrations and automation; if the store itself is being built or rebuilt, see Custom e-commerce development. Send questions via the contact page.

Sources