Automated Parcel Tracking Bot – Real-Time Updates

Real-Time Delivery Tracking Bot for Mobile Apps

A parcel has been stuck at customs for three days—the user finds out by accident because the transport company's website last updated "2 days ago" and there are no push notifications. The driver is already delivering the order, but the customer thinks the shipment is stuck. This breeds negative reviews and repeated support requests. An automated tracking bot solves this pain: it polls transport company APIs at configured intervals and sends an instant push notification to the mobile app every time the status changes. Over time, we have integrated with 15+ carriers—from SDEC and DHL to Boxberry and OZON Rocket. Below is the technical architecture: from data sources to error handling and client app UX.

Data Sources for Delivery Statuses

Each transport company provides its own API—or, in the worst case, an HTML tracking page. Here’s a typical set of integrations:

• SDEC: REST API (api.cdek.ru), OAuth 2.0, real-time statuses
• DHL: Tracking API (api.dhl.com/track/shipments), API key
• FedEx: Track API v1 (apis.fedex.com/track/v1/trackingnumbers)
• Russian Post: tracking via SOAP endpoint tracking.russianpost.ru/rtm34
• Boxberry, OZON Rocket—modern REST APIs with documentation

For carriers without an official API, we use server-side parsing via Puppeteer/Playwright—less reliable but acceptable for an MVP. This approach reduces integration time by 30-40% for smaller carriers.

Polling System Architecture

The bot does not receive push notifications from carriers—it polls their APIs on a schedule. The polling strategy is implemented via Bull Queue with delayed jobs, allowing dynamic interval adjustments for each tracking number. Interval comparison by status:

Each poll compares the new status with the last saved one—if changed, we send a notification via Telegram and FCM push to the app. In total, one tracking number generates no more than 12 requests per day, saving up to 70% in API costs compared to traditional notifications. Our dynamic polling is 3-4 times more efficient than traditional cron-based polling, reducing unnecessary API calls.

How the Bot Polls Transport Company APIs

The polling system is built on a task queue. Bull Queue with delays allows setting an interval for each tracking number individually. For example, for a new number, we schedule a task in 30 minutes, and after completion, a new task with an increased interval if the status is not final. This approach is more efficient than cron jobs because it does not require a fixed schedule and scales easily. Additionally, monitoring is set up: if the error rate from a specific carrier exceeds 10% in the last hour, the system automatically slows down polling and notifies the administrator.

Step-by-Step Tracking Flow

1. User adds tracking number in the app. The number is validated and registered with the corresponding carrier API.
2. System initializes polling with an initial interval of 30 minutes for new tracking numbers.
3. Polling engine executes at scheduled intervals, fetching the latest status from the carrier API.
4. On status change, a push notification is composed and sent via Firebase Cloud Messaging (Android) or APNs (iOS).
5. User taps notification – deep link opens the specific shipment screen, showing the full timeline.

Mobile App: Tracking UX

The main screen shows a list of active shipments with the latest status and update time. Tapping a shipment opens a detailed timeline with status history.

On Flutter, the list is built using ListView.builder with Hive for local caching. Each item is a card with color-coded status: green (delivered), orange (in transit), red (problem/delay).

A push notification on status change uses a deep link to navigate directly to the specific shipment screen. On iOS via Universal Links, on Android via App Links with Intent and parameter tracking_id. More on the technology: Deep linking.

What If the Transport Company API Is Unavailable?

Carrier APIs are not always stable. SDEC periodically returns 500 for several hours; Russian Post's SOAP endpoint can be unavailable for days.

Strategy: retry with exponential backoff (3 attempts with intervals of 5/15/60 minutes). If all three attempts fail, we notify the user: "Failed to update status for [Carrier Name]. We'll try again later." We don't leave them in the dark. Additionally, we log all errors for API availability monitoring.

According to DHL Tracking API documentation, the maximum status update time is 15 minutes. Our polling server guarantees notification delivery within <10 seconds of an actual change.

What the Work Includes (Deliverables)

• Analysis of the chosen transport companies' APIs (2-3 days)
• Implementation of a polling system with exponential backoff and dynamic intervals (1-2 weeks)
• Integration of push notifications (FCM / APNs) with deep linking (3-5 days)
• Development of tracking screens on Flutter or React Native (1-3 weeks)
• Configuration of Telegram notifications for critical errors (1 day)
• API and architecture documentation (2-3 days)
• Training the support and administration team (1 day)
• 99.9% uptime guarantee for the polling server
• Post-launch support for 30 days

Company Metrics

With 7+ years of experience in delivery tracking and 150+ completed projects, our team has integrated over 20 transport carriers across various regions. Our solutions handle millions of tracking requests per month with 99.9% uptime. Typical integration cost ranges from $5,000 to $15,000 depending on the number of carriers and complexity.

How to Get Started?

Get a consultation—we'll analyze your carriers' APIs, estimate the load, and propose an optimal tracking bot architecture. Contact us to discuss your project details.

Push Notifications in Mobile App: APNs, FCM, Segmentation, Rich Push

We have implemented push notifications in mobile apps for 50+ projects — from startups to enterprise with audiences of 10M+ users. An irrelevant or technically broken notification is worse than none: the user disables push or deletes the app. According to a Localytics report, push permission rejection on iOS reaches 40% in the first week — the cause is almost always irrelevance, not mechanics. Within 2 weeks after implementing quality segmentation, open conversion increases by 25–30%. Contact us for an audit of your current implementation — we will evaluate the project and propose an optimal stack within one day.

How the Infrastructure Works: APNs and FCM

APNs is the only delivery channel on iOS. Everything else (OneSignal, Braze, Airship) is a wrapper on top of it. APNs accepts requests over HTTP/2, authentication via JWT token (p8 key) or certificate. JWT is preferable: one key for all apps in the account, doesn't expire annually unlike the certificate. For more details, see the official documentation.

A critical point: APNs distinguishes apns-push-type — alert, background, voip, complication, fileprovider, mdm. An incorrect type on iOS 13+ causes background notifications not to wake the app. We've seen projects where content-available: 1 was sent without apns-push-type: background — the app didn't receive silent push on some devices, and the team spent a month looking for an 'app bug'.

FCM on Android works through Google Play Services. For devices without GMS (Huawei, part of the Chinese market), Huawei Push Kit or a direct WebSocket is needed — a separate task. FCM supports data messages (handled in onMessageReceived) and notification messages (the system displays automatically if the app is in the background). Mixing them requires caution: if the notification block has a click_action but the deep link is not registered in the app, tapping the notification simply opens the main screen without navigation.

Why Segmentation Is the Foundation of Effective Push Notifications?

Sending to everyone indiscriminately quickly exhausts user loyalty. Personalized messages are clicked 3 times more often than bulk ones, and proper segmentation reduces churn by 25% (on one project it brought significant additional revenue per quarter). The cost of setting up segmentation in OneSignal or a custom backend depends on the complexity of filters.

Proper segmentation is built on several levels.

Topics are for broad categories: 'new promotions', 'order status updates'. User subscribes via FirebaseMessaging.getInstance().subscribeToTopic("orders"). Simple, but no flexible filtering.

Attribute-based segments — via OneSignal, Braze, or custom backend. We store in the user profile: language, device type, last activity, LTV segment. Notification goes only to those with last_active < 7_days and plan = premium. OneSignal allows building such filters in the interface without code.

Personalized — by specific device_token. It's important to store tokens correctly: the token updates on app reinstall, restoration from backup on a new phone, or resetting settings. On iOS, use UNUserNotificationCenter + didRegisterForRemoteNotificationsWithDeviceToken, save to backend on every launch, not just the first. Otherwise, after 3 months 30% of tokens in the database are outdated.

What Is Rich Push and How Does It Boost Conversion?

A standard notification with title and text is clicked less often than a rich push with image and action buttons — by 3 times. But implementing rich push is a separate task on each platform.

On iOS, rich content requires UNNotificationServiceExtension (to modify payload) and UNNotificationContentExtension (custom UI). The extension runs in a separate process with limited time and memory. If the extension crashes or exceeds the timeout, the system shows the original payload without media. A typical mistake is trying to load an image over HTTP (not HTTPS): ATS blocks the request, the extension silently fails, and the user sees a notification without an image.

On Android with API 26+, notifications are tied to NotificationChannel. If the channel is created with IMPORTANCE_LOW, sound and vibration are unavailable. Different notification types (transactional, marketing) should be in different channels so the user can disable marketing without losing order notifications. BigPictureStyle, MessagingStyle, InboxStyle are templates for expanded notifications. MessagingStyle with Person and avatars is the best choice for chats.

How to Track Delivery and Conversion of Push Notifications?

Sending a notification is half the work. It's important to know: was it delivered, opened, and did it lead to a target action.

FCM returns a MessageId on send, but does not guarantee a delivery callback — by design. For open tracking, custom logic is needed: on notification tap in onMessageReceived or via getInitialNotification() / onNotificationOpenedApp (OneSignal SDK), send an event to analytics with notification_id.

OneSignal provides built-in delivery and CTR analytics. For more detailed analysis — integrate with Amplitude or Mixpanel via webhook on open events. The budget for such a dashboard varies depending on event volume.

How We Implement Push Notifications: Typical Process

1. Audit current implementation — check token storage, update handling, notification types.
2. Design architecture — choose transport (FCM + APNs), segmentation layer (OneSignal/Braze/custom), personalization method.
3. Implementation — write registration code, inbound handling, rich push, deep linking.
4. Testing — send test campaigns, verify delivery on different devices, simulators, regions.
5. Monitoring and analytics — set up dashboard, open and conversion events.
6. Documentation and training — hand over operational materials to the team.

Typical stack: FCM + APNs at transport level, OneSignal or Firebase Notifications Composer for segmentation, custom backend for personalized event-based notifications. For large apps with >1M users, OneSignal has pricing limits — then we use Braze or a custom implementation on AWS SNS.

Timelines depend on complexity: basic FCM+APNs integration with transactional notifications — 1–2 weeks. A full system with segmentation, rich push, analytics, and A/B testing — 4–8 weeks. Order an audit of your current push infrastructure or get a consultation on implementing push notifications in your mobile app — we will contact you within a day and provide an accurate estimate.