Share your ideas with us

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.

Upload label manually from external source and link (instead of file only) Today its only possible to upload label manually through file via computer.   Hope this will change and we ca upload via external url

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.

I was just tracking my packages and thought of something and was like man I wish there would be different layouts or sorting options. Like if I could sort it by ETD Dates, etc rather than just having them all listed and me doing the mental math of 3 days from now would be Friday, etc. Since of our would be able to be listed by delivery date I would know what packages I need to be on the lookout for that day at an early glance.

It would be really useful to see how often the Gift Tracking Page is actually being used, separately from the regular tracking page. At the moment, it’s hard to tell uptake or performance unless the page has a unique URL or rely on Google Analytics. Having native reporting in AfterShip would make this much easier. Ideally this would show: - Views and unique visitors for the gift tracking page - How it compares to the standard tracking page - Basic engagement (e.g. CTA clicks) This would help merchants understand adoption and value of the gifting feature much more clearly.

I am the owner of a fashion company preparing to expand my business operations in the US. I have been utilizing Aftership EDD for some time now and I'm interested in learning how to configure my EDDs to accommodate multiple locations.   Specifically, I have two separate locations in Australia and the US where identical SKUs are stocked. In cases where a particular SKU is out of stock at the US location, I would like orders to be fulfilled using available stock from the AU location as a fallback option. I am seeking guidance on integrating this specific logic into my EDD settings.

Items + return reasons are not clearly highlighted/shown as selected, during the Return Request flow on the RC portal.    Request: During the return flow more clearly define that an item/return resolution is selected. i.e. have text say “Selected” or have the box change colour when an item/resolution is selected beyond just the black box. 

the only customization allowed is subject line and preview text for the reminder email, can't change the body copy of the reminder email.    benefit would be to add a secondary reminder of receiving loyalty points/an incentivization 

For instance, customers can quickly locate reviews based on size, incorporate images and videos, consider age, product characteristics, and the reviewer's recommendation status.

As a retailer, it would be great if customer preferences can be collected and determine whether to send an SMS notification based on the subscription status synchronized via API.   Moreover, a customer-facing page that allows users to manage their preferences would be even better. We would love to communicate more with our shoppers, which will efficiently improve our customer satisfaction and brand reputation.