Share your ideas with us

The vendor/supplier's email should be copied when sending any type of response to the customer regarding a return.  This includes the RMA confirmation of return, tracking label and when it is received, refunded and resolved.   We/supplier are getting chargebacks through Shopify from customers stating that their returns are not refunded in a timely manner and we have no way to get the email to show that it was processed in Aftership and to dispute a chargeback with shopify.   We have no copies sent to us.   Please fix this issue in Aftership/Shopify immediately.  Thank you. 

There's quite a few couriers where the 'View on Carrier Website' doesn't take you directly to the trracking page, and instead requires you to enter the tracking number.  These can be easily fixed by correcting the URL.   For example, for Cainiao the link takes you to; https://global.cainiao.com/   This needs correcting to; https://global.cainiao.com/newDetail.htm?mailNoList=   Please submit any further examples below.

Related to BOPIS Track - set a Pickup deadline date and use it as a Merge Tag on Notifications.   Ideally, set a date and time expiration date so the end consumer know when they need to pick up their order. If the end consumer doesn't pick up their package before the expiration date, then cancel the order, notify the client and possibly refund the end consumer.

Fast and reliable delivery plays a vital role in customer satisfaction for heavy equipment buyers. When products arrive on time and in perfect condition, it builds trust, reduces downtime, and encourages repeat business and brand loyalty.

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

My package is currently reading that it is out for delivery in my area, but is still showing to be located in a totally different country so the tracking needs to be updated and fixed because this has been an ongoing issue that I've contacted them about for support and it's still reading the same way

So, as a seller who often runs campaigns, I would love to have a cool discount setup that can be customized based on how customers behave.   For example, I could keep discounts hidden for shoppers with shopping carts over $1,000 but display them for those who have smaller carts, so that they would shop more to get a better discount.   This strategy can be effectively applied to our product recommendations, enhancing conversion rates and boosting average order values.

We'd like the ability to restrict which order-editing options are available on a per-country basis, rather than applying the same set of options globally.   Many merchants work with regional checkout or fulfillment partners (e.g. Global-E) that prohibit certain order changes after an order is placed in specific countries. For example, a merchant might need to limit editing to only "apply discount code" and "cancel order" for a subset of countries, while keeping the full set of editing options available everywhere else.   Being able to configure order-editing permissions by country/region would help merchants stay compliant with regional partner restrictions without giving up flexibility in other markets.

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.

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.