Share your ideas with us

Enable merchants to customize the duration before an RMA is automatically canceled. Currently, the system only allows for auto-cancellation after 28 days of inactivity. To better suit our company's needs, we would like the option to extend this period.

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

The current capability features a static returns approval notification. There are instances where the approval notification should be customized before being sent to the customer. Currently, the only way of doing this is to change the approval notification for all returns, save, go back to the RMA in question, approve it with the new notification, make sure no other returns are approved, go back to the nofication and amend it to how it was prior and save.   Use case: there may be a specific product that is available for exchange in store, this needs to be checked with the store first so cannot be a hard rule. If the approval notification could be amended on an adhoc basis, you could give the customer the option at the point of approval and avoid back and forth via email.

Can we have a way to export the report of the notifications? So for example, I would love to be able to export the list of people who had bounced emails for our shipping notifications or even to export the list of folks who did not open the message. 

Allow me to still refund if I choose even if the return request has expired. Now I have to recreate the return request making more work for me.

I would find it very useful if I could pull the SMS communication metadata using an API. Currently it is only available as a download from the portal which makes automation impossible.

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.

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 work in the furniture industry with thousands of products and continuous new product listings.   Consumers often inquire about variations in materials and sizes between similar pieces of furniture, placing a significant burden on my support team. Generating comparison pages for every query we receive is unfeasible due to the volume of requests.   Given the potential of AI to suggest comparable items, could it also be leveraged to pinpoint disparities among products and present these distinctions to consumers? Such a system can alleviate my workload significantly and potentially reduce bounce rates as well.

In Shopify, merchants cannot identify which orders were combined in TTS. This will increase the risk of merchants repeatedly fulfil the same order items.   To address this issue proactively, I would recommend that we introduce a hint or tag within Shopify to alert merchants about combined orders, thus avoid this situation from happening.