How to Build a Shipment Tracking App with Bubble

Building a shipment tracking app with Bubble gives logistics teams and e-commerce businesses a branded, real-time visibility tool that connects carrier data to customer notifications.

Carrier portals are generic and disconnected from internal systems. A purpose-built Bubble tracking app centralizes shipment data, automates customer notifications, and surfaces the status intelligence operations teams actually need.

Key Takeaways

• Tracking events are the core data type: A Tracking Event record for each status change creates the timeline view and drives all customer notification logic.
• Carrier API integration is the data source: The API Connector polls carrier APIs or receives webhooks to populate tracking events automatically.
• Public tracking links use unique tokens: Bubble pages can be accessed without login using a shipment token in the URL, enabling customer-facing tracking without account creation.
• Proof of delivery capture closes the loop: A workflow that accepts a photo upload and signature from drivers completes the tracking lifecycle.
• MVP builds take 6 to 10 weeks: Core tracking, customer notifications, and a carrier portal are achievable in that window.

Bubble App Development

Bubble Experts You Need

Hire a Bubble team that’s done it all—CRMs, marketplaces, internal tools, and more

Let's talk

What Is a Shipment Tracking App — and Why Build It with Bubble?

A shipment tracking app is a platform that aggregates carrier status updates, displays a shipment timeline to customers and operations staff, and triggers notifications when shipment milestones are reached.

Understanding Bubble's pros and cons helps teams assess whether Bubble's API integration layer and workflow engine can meet the real-time update requirements of their tracking use case.

Bubble handles shipment tracking well because the core problem is receiving data from carrier APIs, writing it to a database, and presenting it in a timeline. Each step is a native Bubble capability.

• API data ingestion: The API Connector handles both polling-based carrier API calls and webhook receiver endpoints for real-time status pushes.
• Timeline display: Bubble's repeating group renders tracking event records as a chronological timeline with status labels and timestamps.
• Public page access: Bubble pages can load based on a URL parameter (the tracking number) without requiring user authentication, enabling customer-facing tracking links.
• Notification automation: Backend workflows trigger SendGrid emails and Twilio SMS messages automatically when key tracking events (Out for Delivery, Delivered, Exception) are created.
• Multi-carrier support: A single Bubble app can connect to multiple carrier APIs simultaneously, normalizing their different status formats into a unified tracking event model.

Shipment tracking is one of the most requested logistics Bubble use cases because the ROI on eliminating inbound "where is my order" inquiries is immediate and measurable.

What Features Should a Shipment Tracking App Include?

A shipment tracking app must capture status events from carriers, display a tracking timeline, notify customers at key milestones, and capture proof of delivery. Additional features layer in operational analytics and exception management.

Design the feature set around the tracking lifecycle: shipment created, carrier picked up, in transit events, out for delivery, delivered or exception. Every feature maps to a stage in this chain.

• Tracking timeline: A chronological display of all Tracking Events for a shipment, showing status, location, timestamp, and carrier reference at each stage.
• Public tracking page: A non-authenticated Bubble page that loads a shipment record based on a tracking number URL parameter, giving customers a branded tracking experience.
• Customer notifications: Automated email and SMS alerts sent when tracking events matching key milestone types (Picked Up, Out for Delivery, Delivered, Exception) are created.
• Carrier API integration: Scheduled or webhook-driven workflows that pull status updates from carrier APIs (FedEx, UPS, DHL, custom 3PL) and create Tracking Event records.
• Proof of delivery capture: A mobile-optimized page where drivers upload a delivery photo and capture a recipient signature, recorded as a POD record linked to the shipment.
• Exception management: A flagging workflow that identifies shipments with Exception events and routes them to an operations queue for manual review and customer outreach.
• Operations dashboard: An internal view showing all active shipments, their current status, days in transit, and exception flags for operations team oversight.

An optional customer portal with login lets repeat customers view all their shipments and configure notification preferences for a more polished branded experience.

Estimated delivery date calculation adds significant customer value with modest workflow complexity. When a Picked Up tracking event is created, a workflow calculates an estimated delivery date based on the carrier's historical transit time for that lane (origin to destination region). Store historical transit times as a Transit Time data type per carrier and lane pair, updated monthly by a scheduled workflow that averages actual delivery times from completed shipments. Surface the estimated delivery date prominently on the public tracking page.

Batch notification management prevents notification fatigue for customers receiving multiple status updates in a short window. A high-frequency carrier may push five location scan events within an hour during long-haul transit. Rather than sending an email for each scan, a notification aggregation workflow groups multiple In Transit events into a single daily summary email. Reserving individual immediate notifications for milestone events (Picked Up, Out for Delivery, Delivered, Exception). Configure the aggregation threshold as a customer preference setting.

How Do You Structure the Database for a Shipment Tracking App in Bubble?

The Bubble database centers on a Shipment data type linked to Tracking Event, Carrier, and Customer records. The Tracking Event type is the most important because it creates the timeline and drives all automation.

Use a normalized status option set for Tracking Events so workflows can condition on predictable values regardless of which carrier generated the original status string.

• Shipment: Fields include tracking number (text), internal reference (text), carrier (Carrier), customer (User or text for non-authenticated), origin (text), destination (text), estimated delivery (date), current status (option set), last update (date), and public token (text, unique random string).
• Tracking Event: Fields include shipment (Shipment), raw status (text), normalized status (option set: Created, Picked Up, In Transit, Out for Delivery, Delivered, Exception, Returned), location (text), event timestamp (date), carrier message (text), and source (option set: API Poll, Webhook, Manual).
• Carrier: Fields include carrier name (text), API type (option set: REST, SOAP, Webhook), base URL (text), API key (text, private), polling interval minutes (number), and active (yes/no).
• Customer: Fields include company name (text), contact email (text), contact phone (text), notification preferences (option set list), and account type (option set: Standard, Enterprise).
• Proof of Delivery: Fields include shipment (Shipment), delivery photo (file), signature image (file), recipient name (text), delivery timestamp (date), GPS coordinates (text), and recorded by (text).
• Notification Log: Fields include shipment (Shipment), notification type (option set: Email, SMS), event trigger (option set), sent timestamp (date), recipient (text), and delivery status (option set: Sent, Failed).

The public token field on Shipment is critical for the non-authenticated tracking page. It should be a randomly generated string assigned on creation, not the tracking number itself.

How Do You Build the Core Workflows for a Shipment Tracking App in Bubble?

Core workflows handle carrier data ingestion, tracking event creation, status normalization, customer notification, and proof of delivery capture. These run as backend workflows on schedules and webhook triggers.

The status normalization step is the most important workflow component. Carrier APIs return inconsistent status strings. Normalizing them to a standard option set makes all downstream automation reliable.

• Carrier API poll workflow: A scheduled backend workflow runs every 10 to 30 minutes (configurable per carrier), calls the carrier API via API Connector for all active shipments, and passes each status response to the event creation workflow.
• Tracking event creation: For each API response, the workflow checks whether an identical status event already exists for the shipment (to prevent duplicates), then creates a new Tracking Event record with the raw status, normalized status mapping, location, and timestamp.
• Status normalization logic: A workflow step maps the carrier's raw status strings to the normalized option set using Bubble's conditional logic. For example, FedEx "In Transit" and DHL "On the Way" both map to the In Transit option.
• Customer notification trigger: When a Tracking Event is created with a normalized status matching a notification milestone, a workflow sends a SendGrid email and optional Twilio SMS to the customer, logs the notification in the Notification Log, and updates the shipment's current status field.
• Exception escalation: When a Tracking Event with normalized status Exception is created, the workflow flags the shipment, creates an internal alert for the operations queue, and sends an expedited customer notification.
• Proof of delivery workflow: When a driver submits the POD form, the workflow creates a POD record, changes shipment status to Delivered, creates a final Tracking Event, and sends the customer a delivery confirmation with the POD photo attached.

Webhook receiver endpoints for carriers that support push delivery eliminate polling delay and reduce Bubble workflow run counts on high-volume builds.

What Security and Data Requirements Apply to a Shipment Tracking App?

Shipment tracking apps contain customer personal data, commercial route information, and carrier API credentials. Proper security configuration protects all three without degrading the customer tracking experience.

Securing data in Bubble requires configuring privacy rules at the data type level. For tracking apps, the public tracking page needs special handling because it intentionally allows unauthenticated access.

• Public tracking page security: The public page should load Shipment data only when the URL token matches the public token field exactly. Never expose the internal database ID in the URL. Token-based lookup prevents enumeration attacks.
• Customer data isolation: Authenticated customers should see only their own Shipment records. Set privacy rules so the customer field must match the current user for all read operations.
• Carrier API credential protection: Store carrier API keys in Bubble's server-side environment variables, not in the Carrier data type fields. Backend workflows access these variables directly without exposing them to client-side queries.
• Driver access scope: Drivers accessing the POD capture page should see only shipments assigned to them with a status of Out for Delivery. Completed or unassigned shipments should not be accessible.
• Notification log access: The Notification Log should be read-only for all non-admin roles. It serves as an audit trail and should not be modifiable after creation.
• GDPR and data retention: Customer email and phone data used for notifications should have a documented retention period. Scheduled workflows can anonymize contact fields on completed shipments after the retention window.

Token-based public access combined with server-side API key storage covers the two highest-risk security vectors in tracking app builds.

What Plugins and Integrations Does a Shipment Tracking App Need?

A shipment tracking app needs carrier API connectivity, map rendering, notification services, and file handling for proof of delivery. The integration list is focused and manageable for an MVP build.

Prioritize the carrier API integration setup early in the build. Carrier APIs vary significantly in quality, authentication methods, and rate limit policies. Discovering integration challenges late causes timeline overruns.

• API Connector: The essential plugin for connecting to carrier APIs (FedEx, UPS, DHL, custom 3PL APIs) using REST or SOAP calls with authentication headers configured per carrier.
• Google Maps plugin: Renders shipment origin, current location, and destination on a map in the tracking timeline, using location strings from Tracking Event records.
• SendGrid plugin: Handles all customer notification emails with branded HTML templates for each tracking milestone type.
• Twilio plugin: Sends SMS updates to customers who opt in to text notifications for delivery milestones and exception alerts.
• File upload handling: Bubble's native file uploader handles POD photo capture. For high-volume POD storage, an S3 plugin routes files to external storage with a URL written back to the POD record.
• Bubble's built-in scheduler: Powers the carrier API polling workflows on configurable intervals without external cron infrastructure.

How Long Does It Take and What Does It Cost to Build a Shipment Tracking App with Bubble?

A shipment tracking app MVP takes 6 to 10 weeks with an experienced Bubble developer and costs between $15,000 and $40,000 depending on the number of carrier integrations and portal scope.

Review Bubble's pricing plans before scoping the build. High-frequency carrier API polling workflows and large shipment databases require Growth or Production plan capacity to avoid hitting workflow and storage limits.

• Carrier count impact: Each additional carrier integration adds 8 to 15 hours for API setup, status normalization mapping, and integration testing.
• Bubble plan requirement: Growth plan handles scheduled API polling. High-volume builds with hundreds of daily shipments and frequent polls need Production plan database and workflow capacity.
• Webhook vs polling: Webhook-based carrier integrations (where the carrier pushes updates) are more complex to set up but reduce Bubble workflow run consumption significantly.
• Multi-language tracking pages: Adding language localization to the public tracking page adds 10 to 15 hours for content management and conditional text display.

Monthly operating costs after launch typically run $200 to $600 covering Bubble hosting, Twilio, SendGrid, and any per-call carrier API fees.

Conclusion

Bubble is a practical platform for shipment tracking when the Tracking Event data type is clean and public page security uses token-based lookup rather than database IDs. Getting these right prevents the most common tracking app failures in production.

Teams replacing manual shipment status emails with automated carrier-connected tracking can reach a production-ready Bubble app in under ten weeks.

Bubble App Development

Bubble Experts You Need

Hire a Bubble team that’s done it all—CRMs, marketplaces, internal tools, and more

Let's talk

Build Your Shipment Tracking App with Expert Support

Shipment tracking apps depend on carrier API integration, status normalization across multiple providers, and public page security that must hold up under enumeration attempts. Carrier API format inconsistencies and incorrectly configured webhook endpoints are the most common failure points.

At LowCode Agency, we build Bubble apps as a full product team - not a dev shop that hands off code. We scope the architecture, engineer the workflows, and stay involved through launch and beyond.

• Data architecture: We design your data types, option sets, and privacy rules before writing a single element on the canvas.
• Workflow engineering: We build backend workflows, scheduled jobs, and API integrations with proper logic and error handling.
• Plugin configuration: We select and configure the right Bubble plugins for your feature set without unnecessary bloat.
• Role-based access: We implement privacy rules at the database level, not just conditional UI visibility.
• Integration setup: We connect your Bubble app to Stripe, SendGrid, Twilio, and other services correctly from day one.
• Pre-launch testing: We test against real data before deployment so every workflow performs correctly under live conditions.
• Post-launch support: We stay involved after go-live to optimize as real usage data shapes the app.

We have built 350+ products for clients including Coca-Cola, American Express, Sotheby's, and Medtronic. We know exactly where Bubble builds fail and we address those problems before they surface.

If you want your Bubble app built correctly from day one, let's scope it together.