Share your ideas with us

Suggestion: Add Lazada Express (LEX MY / LEL) Support for Malaysia   Hi,   I would like to suggest adding Lazada Express (LEX MY / LEL) as a supported courier/carrier on your app and website.   Lazada Express is the official delivery courier used by Lazada in Malaysia, similar to how SPX Express / Shopee Express is the official courier for Shopee. Many Lazada shipments in Malaysia are handled by LEX, so having direct tracking support would be very useful for Malaysian users.   The official LEX Malaysia tracking website is: https://lex.com.my/   For testing purposes, you can use these example tracking numbers:   LXST191548638MY MYMPA257159996   I hope you can consider implementing Lazada Express (LEX MY / LEL) support soon. As Lazada is widely used in Malaysia, I believe many users would appreciate being able to add and track their LEX shipments directly through your app and website instead of having to visit the LEX website separately.   Thank you for considering this suggestion. I hope LEX MY support can be added in a future update!

While using personalization, I want to understand the actual product results generated by these algorithms and the reason behind the chosen product displays for shoppers.   If I can preview the recommendation results in the admin, it would reduce uncertainty, ensure optimal outcomes, and improve my marketing strategies to boost conversions.

Hello,  We currently use AfterShip Feed to connect our Amazon Seller account to TikTok Shop. But it would be fantastic to be able to also connect with Walmart Seller's MCF. It would allow even greater reach of products on more sales channels.

1. What is the context?  * We are currently a Premium plan subscriber operating a high-volume merchant shipping 68% of our Canadian orders via GLS Canada. We are looking to utilize the Enhanced MPS Visibility feature to improve our customer experience.   * Currently, your documentation lists carriers like FedEx, UPS, and DHL as supported for MPS, but GLS Canada is excluded. When we contacted support, we were told this is due to "carrier limitations.   2. What issue do you want to address? We believe the "carrier limitation" rationale may be outdated or incorrect because AfterShip is already successfully pulling data for GLS child packages. * Evidence: On GLS Canada tracking number P97186751, AfterShip retrieves events for both Package 1 (Delivered Nov 21) and Package 2 (Delivered Nov 19). * The Problem: Because GLS Canada is not on your "Supported Carriers" list for MPS logic, your system aggregates these distinct events into a single "scrambled" timeline instead of separating them into tabs. * The Gap: The data exists in your system; the parsing logic to separate "Master" vs. "Child" is simply missing for this specific carrier. 3. What outcome do you expect? * We request that the product team add GLS Canada to the Enhanced MPS Visibility supported carrier list * We need the system to recognize the child packages it is already detecting and display them in separate tabs (Piece 1, Piece 2), just as it does for FedEx or UPS.   4. Who will benefit from your idea? * Merchants: This allows Canadian merchants to use your Enterprise MPS features for their dominant carrier, reducing support tickets regarding "confusing" status updates. * AfterShip: It improves the value of your Enterprise plan for the Canadian market by supporting the region's major logistics provider.

Would you be able to: 1. Add a functionality that restricts order views based on a ship from location or/or login? We have multiple ship from locations and we are 100% manula orders; it creates confusion when one warehouse sees orders from another warehouse.  2. Have a ship to address book and have that be varied based on ship from locations. We have set ship to locations and it doesnt change often. 

Currently OTD report, reports the complete journey so the avereage time can fluctuate based on how long it takes for customers to collect their order.  We need to report on the carrier performance and then the time it takes to collect.  It would be good to have  a PUDO report that breaks down : average transit time to collection point   Average time waiting for collection    If we expand our PUDO options in Europe it would be a good indication 

It would be incredibly helpful if there was a way to export the shipping data from the phone app. It would be extremely simple and improve the apps usefuleness.    It would also be incredibly helpful if there was a way to have the phone app on the computer. I know the browser version is different and designed for merchants while the phone app is designed for recipients. But, it would be easy to create a aftership.com/recipients version of the app on the computer that just syncs the shipments across devices. 

Instead of directly integrating Aftership with Gmail, I would like to send my emails with package information to an aftership email address associated with my account, for aftership to parse and automatically show tracking information. 

it would be great to be able to manually add a placeholder delivery in order to keep track of my deliveries.

Currently, AfterShip's webhook outgoing IP list is only available on an HTML documentation page (https://www.aftership.com/docs/tracking/webhook/webhook-outgoing-ips). This makes it impossible to automate IP allowlist management in infrastructure-as-code (IaC) workflows.   Problem: Teams that use IP-based firewalls to secure their webhook endpoints must manually monitor the documentation page for any IP changes and update their firewall rules accordingly. If a change is missed, it can cause webhook delivery failures and broken integrations.   Request: Please publish the webhook outgoing IP list as a dedicated plain-text endpoint — similar to how Cloudflare publishes theirs at https://www.cloudflare.com/ips-v4 — where each IP is returned on a separate line.   This would allow teams to: * Fetch the IP list programmatically as part of their CI/CD or IaC pipelines * Keep firewall allowlists automatically in sync without manual intervention * Avoid service disruptions caused by missed IP changes This is a standard practice among major API providers and would significantly improve the developer experience for customers who manage network security programmatically.