Why Europochta integration breaks delivery scenarios in the app
Europochta integration into a mobile app almost always starts the same way: the developer connects the carrier's official API, gives the customer a choice of branch, receives a shipment number — and everything works in the demo.
What breaks is not the connection but day-to-day operation. Each order lives longer than one session: it is created, paid for, tracked, received, returned, and at every transition the app must know the current state of the shipment.
The first source of failures is desynchronization of shipment statuses.
The app shows “ready for pickup,” but the shipment has already been returned to the sorting center, or vice versa: the customer sees “in transit” and does not go to the branch, even though the parcel has been sitting there for three days.
The reason is that the carrier's service reports events not instantly and does not guarantee their order, while the app either polls the state on a schedule or updates it only when the screen is opened.
Without handling duplicate and stale events, shipment statuses begin to contradict each other, and the customer loses trust in the tracker.
The second failure point is the carrier's service being unavailable at the moment the order is placed.
A failure on its side, scheduled maintenance, or a timeout when retrieving the list of branches turns into errors during checkout: the customer filled the cart, selected delivery in the mobile app, and received an error message at the last step.
The order may already be paid, but the waybill has not been created — the discrepancy has to be found manually, and it surfaces only when the customer calls support.
The third is manual entry of shipments and manual reconciliation of statuses in the carrier's panel. While some orders are created by an operator, discrepancies appear in the app: an incorrect number, a lost order—shipment link, duplicates.
Support load grows not from complex requests but from repetitive “where is my parcel” inquiries. Below we discuss how these scenarios are handled and what exactly needs to be provided for in the app.
What changes after integration: statuses, timelines, returns
Connecting the carrier's logistics moves the choice of delivery method and the calculation of time and cost into the app itself — before the order is confirmed.
The buyer sees the date and interval for a specific pickup point, not an abstract “3–5 days,” and this removes the main reason for abandoned carts.
Checkout speed increases because the address and pickup point are filled in from history and geolocation, and a repeat order reproduces the previous route in one tap.
If earlier the delivery decision was made at the last step, now it is built into the cart and does not require leaving for the carrier's website.
Delivery timelines in the app stop being a text field: statuses come from the logistics service and are broken down into clear states — accepted, in transit, at the point, delivered.
Each status change generates a notification, so the share of “where is the parcel” requests drops, and the load on first-line support decreases.
Returns and refusals to accept are processed directly from the order card: the buyer selects a reason and sees the return timelines and refund status.
A refusal at the delivery stage also becomes an event in the app, not a call to support, and the warehouse learns about it before the parcel goes back.
For the team, the effect is no less measurable: manual status transfer goes away, discrepancies between the order and the waybill are visible before it is created, and disputed deliveries are investigated using the event log rather than messenger correspondence.
Ways to integrate Europochta into a mobile app
Integrating Europochta into a mobile app is handled in one of four ways, and each distributes responsibility for failures in its own way.
The choice determines how quickly new carrier services appear, what happens when the response format changes on its side, and how much work falls on your team.
The choice rarely comes down to the most modern option — it depends on shipment volume, the number of carriers, and readiness to maintain a separate logistics support function.
| Option | When it fits | Limitations |
|---|---|---|
| Direct carrier integration | one carrier, stable flow, narrow set of services | tied to its API, changes require a new app release |
| Logistics aggregator | several carriers, a single status for the customer | some services are unavailable, statuses arrive with a delay, history is limited |
| Intermediate exchange layer | custom scenarios, status cache, a single format for the app | the layer must be maintained and tested when contracts are updated |
| Manual shipment entry | small volume, pilot launch of a destination | the operator enters data manually, statuses are not pulled in, does not scale |
Most often, teams settle on the intermediate layer: it allows starting with one service and connecting the rest without rebuilding the app.
Before choosing, we look at shipment volume, the set of services, and status requirements, and propose the option with the fewest failure points in your scenario.
Implementation stages: from scenario audit to handover to support
Implementing Europochta integration into an app is not connecting a module according to instructions, but a sequence of steps where each next one relies on the result of the previous one.
We start with an audit of delivery scenarios: we look at how the order is currently placed, where the address and pickup point come from, and which statuses the user already sees.
Without this, the exchange scheme will be built in a vacuum and will fall apart on the first non-standard order.
- Delivery scenario audit. We analyze the current screens and transitions: delivery method selection, address entry, payment, tracking. We record what data the app must send and receive, and where the formats currently diverge.
- Exchange scheme design. We describe in what batches orders are sent, by what attribute statuses are matched, and what to do with cancellations, returns, and partial shipments.
- Data exchange setup. We connect environments, configure the upload schedule and status matching rules, and test on a staging environment — first on prepared data, then on a flow close to production.
- Error and retry handling. Service unavailability, duplicate requests, status mismatch: each case gets its own scenario — retry with delay, limit on the number of attempts, log entry for investigation.
- Acceptance testing on orders. We run real orders: from checkout to delivery, including refusals, returns, and cash on delivery. We compare the status in the app with the carrier's data at every step.
- Handover to support. We provide the scheme description, access to logs, instructions for typical failures, and train the on-call shift; separately, we document how to roll back to the previous version of the exchange.
What remains with the customer: schemes, configurations, regulations
We hand over not “working code as is,” but a package your team can use to independently support and develop delivery.
All artifacts are designed so that an engineer who did not participate in the development can use them: with a description of behavior, edge cases, and the procedure for acting during a failure.
- Integration scheme — the sequence of calls between the app, the delivery service, and Europochta: creating a shipment, calculating cost, tracking statuses, canceling an order. With timeouts, retries, and which errors are considered temporary.
- Environment configurations — sets of connection parameters for test and production environments, rules for key substitution, separation of access between builds, and a switching mode without releasing a new version.
- Responsibility matrix — a table where for each operation (status updates, return processing, address correction, handling unavailable pickup points) it is indicated who is responsible: our side, your support, or the logistics operator.
- Delivery support regulations — what to do when statuses diverge, a shipment is stuck, or the service fails on the operator's side. With response time, escalation procedure, and criteria for when the problem is resolved on our side.
- Logistics documentation — description of reference data, status codes, and their display in the interface, including rare states and localization rules for different countries.
- Data and migration scheme — the storage structure for orders and shipments, the procedure for changing fields without losing history, and the rollback procedure for an unsuccessful update.
- Release and monitoring procedure — how to verify delivery after release, which metrics and logs to check first, and where the boundaries of our and your access are.
The package is updated along with changes in the integration, so the documentation does not diverge from the actual system behavior.
Case study: delivery in a retailer's app before and after integration
Before logistics integration, the retailer's app would place an order and then go silent: the buyer entered the pickup point address as text, the branch number was not validated, and the shipment status lived in a separate tab for the operator.
For some orders, the address did not match the actual branch, and support started the investigation from scratch — “where is my parcel” became the most frequent support topic. The share of successful orders held at around 82%.
What was changed
We connected Europochta directly: the branch directory with a map is pulled into the app, selecting a point became a required checkout step, and shipment statuses come from the logistics service and update in the background while the app is closed.
We separately handled failures — if the service did not respond, the order is not lost but goes into deferred sending, and the buyer sees a clear status instead of an error.
What became
The share of successful orders grew from 82% to 96%, and checkout time was nearly halved — the address is selected in a couple of seconds instead of manual entry.
The flow of “where is the parcel” requests dropped by about 70%: the status is visible right in the order card, and the person does not need to call. Support load stopped growing along with the number of orders — with doubled volume, the line worked with the same staffing.
What to do if the app already has its own delivery module
An existing delivery module does not prevent connecting Europochta, and it almost never needs to be rewritten entirely.
Logistics is moved behind a common contract: the app requests delivery methods, cost, time, pickup points, and shipment status, while each carrier provides this data in its own way.
The existing module becomes one of the contract implementations, the new one is connected alongside — order placement proceeds as usual at that moment.
Before integration, we put reference data in order: regions and localities, branch types, and shipment status codes are consolidated into a single model.
Without this, the status diverges between the tracker, email, and push notification, and support receives discrepancies for the same parcel. We filter duplicate notifications from the logistics service by shipment ID so that duplicate transitions do not appear.
The coexistence of services is built according to one of four scenarios; the choice depends on the state of the code, not on deadlines:
| Option | When it fits | Limitations |
|---|---|---|
| Parallel operation of two modules | need a quick launch of a new delivery method, without touching the code | cost calculation and statuses are duplicated, reference data diverges |
| Common contract, carriers behind it | there will be more than two delivery methods, and there is capacity for refactoring | one-time rework of the existing module |
| Phased replacement by groups | switching without downtime is critical | dual support and metric reconciliation during the transition period |
| Full replacement in one release | the module is isolated and covered by tests | an error breaks order placement, rollback is difficult |
Phased logistics replacement is done not by a release but by configuration: the new method is enabled for a test group, then for a share of traffic, and the share grows as calculated timelines match actual ones.
Rollback is done with the same switch, without deploying a new build. While the services run in parallel, metrics are reconciled line by line: share of successful checkouts, cost calculation time, and discrepancies in shipment statuses.
Common technical questions before integrating logistics
When logistics is built into the app, the customer sees the tracking number and status, while the engineer sees the request queue, error handling, and reconciliation of states between the two systems.
Below are the doubts that most often surface during evaluation: they determine how much time will go into support after launch.
We build this into the architecture from the start: requests to Europochta go through an intermediate layer, not directly from the app interface. The layer stores the queue and response log and allows the operation to be replayed without forcing the user to re-enter data.
What happens if the carrier's service is unavailable?
The request is not lost: it goes into a queue with retries and increasing delay, and the interface shows a clear status “processing.” When the service responds, the operation is completed without user involvement.
Each shipment is recorded in the log with its own ID, so resending the request does not create a duplicate order.
Why do statuses in the app and in the carrier's dashboard diverge?
The sources update with different delays, and this is a normal mode, not a failure. We combine two channels: notifications from the carrier's service and periodic reconciliation by shipment number.
The discrepancy is resolved by source priority, and disputed records go into a report for investigation.
How does the app behave with a poor connection?
The shipment draft is stored locally, so the entered data is not lost when the network drops. Sending is retried when the connection returns, and the user sees the current status, not an empty screen.
All actions with recipient data are available only to an authorized user and are not left in plain text on the device.
Let's discuss the task: what to send and how we will return with an estimate
To return with an accurate integration estimate, rather than a “from and to” range, we need a minimum of initial information. Below is what to send at the start: this is enough to estimate the scope of integration work and see bottlenecks in advance.
- Access to the test and production Europochta environments: keys, credentials, service addresses.
- Documentation for the methods of creating a shipment, calculating delivery, tracking statuses, and working with pickup points.
- The scenario in the app: checkout, payment, tracking, return — which steps and in what order.
- The status scheme and code reference from the service so they can be matched with screens and notifications.
- Requirements for user identification and storage of personal data on the app side.
- Expected load: how many shipments and status requests per day occur at peak.
After discussing the task, we return with an estimate, a connection work plan broken down by stages, and the set of artifacts we hand over.
As a separate item, we describe handover to support: access, logs, the procedure for responding to failures, and the update procedure if the service changes methods or response formats.