Share your ideas with us

Most major carriers already provide an estimated delivery date/time as part of their tracking data, but this isn't currently surfaced in the app. Context: Customers tracking a shipment want to know when it will arrive, not just its current status. Right now they have to infer this themselves or check the carrier's own site separately. Issue to address: Add a field that displays the carrier's estimated delivery date (and time window, where the carrier provides one) on the tracking/order page. This would reduce "where is my order" support inquiries and improve the post-purchase experience. Suggestion: Pull the estimated delivery data from carriers that already expose it via their APIs, and display it prominently near the shipment status.

I am utilizing Smile to develop the Reward program for our business. This year, I aim to motivate members to increase their reviews by integrating Reviews into the reward system as bonus incentives. This will allow our members to accumulate extra points by sharing feedback for their purchases.

The website is in dutch but then after login, the portal is in english.

Hi, The data when the shipment is created at the carrier is important for shipment analysis. Example:  Info received   Shipment information received DHL Express Mar 25, 2025 at 12:01 pm

Brand noted they’d like to be able to clearly communicate why certain Products are on the Blocklist - instead of the general text we have in place, without specifically making the customer review the Policy as a whole. Asking if we could define the error at the Blocklist Product Tag entry level. If the value is left blank, use default content.   Current state: After end consumer logs in with Order, non returnable items are greyed and out and we show at the line level a message that states "Does not comply with our return policy."   Desired State: After end consumer logs in with Order, non returnable items are greyed and out and we show at the line level a message from a configurable setting within RC where we can pass SKU or Product Category specific messages that state why an item is nt returnable like "Digital Goods are not returnable" or "Bundled Item cannot be returned" or "Last years models are not returnable but warranty available".   We'd like to be able to configure our own blocklist message for order item display when the end consumer logs into RC.

We should be able to update the email address on the returns and warranty pages in case the cx is unable to access the default email.

As a merchant, I would like to break down the shipping volume report by Carrier and Lane. Currently, it can be broken down by only one condition.   This would allow us to understand how a carrier is performing in a specific market.

To enhance the shipping experience for customers purchasing hair extensions or hair care products, AfterShip could focus on providing real-time tracking updates that are both detailed and easy to understand. For the hair industry, ensuring timely delivery is critical, as customers expect to receive their products in a timely manner, especially for events like weddings, parties, or other special occasions. Additionally, offering automated notifications at each stage of the shipping process — from dispatch to in-transit updates and delivery confirmation — would allow customers to stay informed and reduce anxiety around the arrival of their products. A specific feature that would be beneficial in the hair industry is providing an estimated delivery window based on the type of hair products purchased, considering how delicate and time-sensitive hair products can be. Another improvement could be offering customized delivery options, like express shipping for urgent orders or delivery tracking tailored to customers’ needs based on their location, enhancing convenience and customer experience. By integrating these features, AfterShip could help ensure a seamless experience for customers in the hair industry, driving satisfaction and repeat business.

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.

I want to be able to mask certain words such as 'flight'and ''import'', or ''customs''. As for EU customers this is not relevant infromation and they faster think goods are from china and want to return faster. When they see basic info and a EDD they are assured everything is good. They dont neem more info.