Share your ideas with us

It would be very helpful to have an option to group orders by store/company name (e.g., all Amazon orders together, all eBay orders together, etc.). This way, I could collapse or expand groups and quickly view only the orders I want. Additionally, it would be great if users could create their own custom groups for even more flexibility.

Hi there, We ship wine, which means orders are often held by our fulfilment center when temperatures along the route are above or below certian threshold we have set. I would like to create a flow that automatically notifies the customer that their order has been flagged for a weather hold and ensures them it is still on the way. Is this possible? Thanks

Currently you can manually refund the shipping fee in the admin manually, but would like the ability for it to be automatic.

Add the option to pay online ~ $2 at checkout for free returns and extended warranty later.    Add tags to people / allow different RMA flow for those who optin to this. 

When using the mobile App, currently shipments remain visible in the tracking list even after they have been delivered. Over time, this can make the main tracking screen feel cluttered, especially for users who receive a large number of packages. It would be very helpful to have an option to: - Archive delivered shipments manually, or - Automatically move delivered shipments to an archive after a certain period of time. This would allow users to keep their active tracking list clean and focused on packages that are still in transit, while still retaining access to past deliveries when needed.   Thank you,

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.

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. 

Good morning, I kindly ask you to enable the option to change the font, font size, colour, etc., for the “address” field within the footer of notification emails. Currently, this is the only field that cannot be customised, which creates a noticeable contrast between the main text in the body and this field, making the emails aesthetically unappealing. Thank you.

We are able to retrieve shipping rates for each carrier, but we would also like customs clearance fees and other charges available through each carrier’s API to be integrated via API as well. This is especially important for DDP shipments. Some information that can be retrieved through the carrier APIs cannot be retrieved through AfterShip, which means we would need to connect to each carrier’s API separately.

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.