【抖音小店】售后订单列表接口：一键拉取退货退款订单，售后处理快人一步

做电商的都知道，售后处理是最耗时耗力的环节。

用户申请退款/退货，商家需要及时处理：审核申请、等待退货、验收退款......任何一个环节延误，都可能导致客诉升级甚至平台罚款。而开发一套自动化的售后管理系统，第一步就是把店铺的售后订单列表拉下来。

今天我们就来分享如何通过深圳小于科技 的抖店接口服务，快速接入售后订单列表接口 ，重点筛选退货退款类型的售后单，让售后处理效率翻倍。

一、为什么售后订单接口这么重要？

先来看看几个真实场景：

场景1：退货退款自动化处理

用户申请退货退款，你需要知道：这笔售后单当前是什么状态？是"待商家审核"、"待买家退货"，还是"待商家收货"？不同的状态需要触发不同的业务动作。

场景2：仓库退货入库联动

买家寄回退货商品后，售后状态变为"待商家收货"。此时需要通知仓库人员：有退货包裹到了，请验收。验收通过后，需要在系统里触发退款；验收不通过，则需要驳回售后。

场景3：ERP售后单同步

将抖店的售后单同步到内部ERP系统，由仓储、财务等部门协同处理，避免漏单、错单。

这些场景都有一个共同点：你需要拉取店铺的售后订单列表，并按状态、类型进行筛选。但官方接口的复杂程度，往往让这个需求变得很"重"。

二、官方接口的痛点：杀鸡用牛刀

痛点1：依然绕不开的审核门槛

哪怕你只是想查一下售后单列表，也得先通过官方3-5天的资质审核。个人开发者想做个内部售后看板？没门。

痛点2：Token问题依然存在

售后接口同样需要access_token。你依然需要处理OAuth2授权、定时刷新token、多店铺token维护......原本只想写20行代码拉个售后列表，结果又得写一堆token管理逻辑。

痛点3：状态枚举复杂，筛选成本高

官方售后状态字段多且分散，光是理解after_sale_status和standard_aftersale_status的区别就得翻半天文档。想筛选"退货退款"类型的售后单，还得自己拼参数。

我们的解决方案：

• 无需审核：注册即用，立即可查
• 无需Token：封装OAuth2，只需三个参数
• 场景预设：提供常用业务场景的filter组合，拿来即用

三、接口文档：售后订单列表查询

通过本接口，你可以查询店铺的售后订单列表，并支持按售后状态、售后类型、申请时间等多种条件筛选。特别适合筛选退货退款类型的售后单。

1. 接口地址

POST ${host_prefix}/api/doudian/afterSale/list

2. 请求参数

请求头：Content-Type: application/json

参数名	必填	类型	说明
appId	是	string	应用AppId（注册后从控制台获取）
appSecret	是	string	应用AppSecret（请妥善保管）
platformShopId	是	string	店铺ID。从"获取用户信息"接口返回的platformShopIdsStr字段中获取
filter	否	object	查询条件对象
└─ after_sale_status	否	string	售后状态：return_receive(待商家收货)、wait_send(待商家发货)、after_sale_audit(待商家处理)、return_ship(待买家退货)、audit_refunding(退款中)、audit_refunded(退款成功)、refund_fail(退款失败)、close(售后关闭)、refuse(拒绝售后申请)、receive_refuse(退货后商家拒绝)、wait_buyer_receive(换货/补寄/维修待买家收货)、reject_sign_refund(拒签后退款)、exchange_success(换货成功)、resend_success(补寄成功)、repair_success(维修成功)。不填写则查询全部。
└─ after_sale_type	否	string	售后类型：presale_all(未发货仅退款)、refund(已发货仅退款)、return(退货退款)、exchange(换货)、price_protection(价格保护)、resend(补寄)、repair_only_exchange(维修-以换代修)、repair_send_repair(维修-寄修)。不填写则查询全部。
└─ search_id	否	string	订单号/售后编号，批量查询用逗号","隔开
└─ search_product	否	string	商品名称/商品ID
└─ apply_time_start	否	long	申请开始时间（时间戳秒），如：1722441600 表示 2024-08-01 00:00:00
└─ apply_time_end	否	long	申请结束时间（时间戳秒）
└─ final_time_start	否	long	完成开始时间（时间戳秒）
└─ final_time_end	否	long	完成结束时间（时间戳秒）
pageIndex	否	int	页码，默认值1
pageSize	否	int	每页记录数，默认值20（可选值：10、20、50、100）

3. 常见业务场景的filter组合

场景：筛选"退货退款"类型的售后单

"filter": {
    "after_sale_type": "return"
}

说明：只查询售后类型为"退货退款"的订单，过滤掉仅退款、换货等其他类型。

场景：筛选"待商家收货"的退货单

"filter": {
    "after_sale_type": "return",
    "after_sale_status": "return_receive"
}

说明：买家已寄回商品，等待商家收货验收。这是退货流程中最需要关注的环节。

场景：筛选"退款成功"的退货单

"filter": {
    "after_sale_type": "return",
    "after_sale_status": "audit_refunded"
}

说明：查询已完成退款的退货单，用于财务对账。

场景：按售后单号精确查询

"filter": {
    "search_id": "6987272148133888300"
}

说明：支持传入售后单号或订单号，精准定位。

4. 请求示例

最简请求（查询所有售后单）：

POST /api/doudian/afterSale/list HTTP/1.1
Content-Type: application/json

{
  "appId": "YOUR_APP_ID_12345",
  "appSecret": "YOUR_APP_SECRET_ABCDE",
  "platformShopId": "doudian_9876543210"
  // 不传filter表示查询所有售后单
}

带筛选条件的请求（查询退货退款类型的售后单）：

{
  "appId": "YOUR_APP_ID_12345",
  "appSecret": "YOUR_APP_SECRET_ABCDE",
  "platformShopId": "doudian_9876543210",
  "filter": {
    "after_sale_type": "return"
  },
  "pageIndex": 1,
  "pageSize": 20
}

5. 响应示例

{
    "msg": "查询成功",
    "code": 200,
    "data": {
        "items": [
            {
                "after_sale_info": {
                    "after_sale_id": "147395553806149795",
                    "after_sale_order_type": 1,
                    "after_sale_type": 0,
                    "after_sale_status": 7,
                    "related_id": "6951060298510767134",
                    "apply_time": 1773362092,
                    "update_time": 1773362094
                    // ... 更多字段请以实际返回为准
                }
            }
            // ... 更多售后单
        ]
        // ... 更多字段请以实际返回为准
    }
}

核心字段说明 （完整字段请参考抖店官方文档）：

字段	说明
after_sale_id	售后单ID
after_sale_order_type	售后订单类型
after_sale_type	售后类型（0-退货退款）
after_sale_status	售后状态（7-待商家收货）
related_id	关联订单号
apply_time	申请时间戳
update_time	更新时间戳

四、典型应用场景

场景1：退货退款自动化处理

定时拉取"退货退款"类型的售后单，根据after_sale_status自动触发不同动作：

• after_sale_audit（待商家处理）：自动审核通过
• return_receive（待商家收货）：通知仓库准备验收
• audit_refunded（退款成功）：同步ERP更新订单状态

场景2：仓库退货入库联动

每分钟拉取状态为return_receive（待商家收货）的售后单，生成退货入库任务推送给仓库系统。仓库验收完成后，调用接口确认收货并触发退款，形成闭环。

场景3：超时预警系统

对比当前时间与status_deadline，对即将超时的售后单推送预警，避免自动退款造成损失。

五、为什么选择小于科技的售后订单接口？

对比维度	官方方案	小于科技方案
接入门槛	需企业资质，审核3-5天	注册即用，无需审核
授权流程	OAuth2，需自维护Token	封装鉴权，只需传appId/secret
多店铺管理	需为每个店铺维护独立Token	一个接口，换店铺ID即可
状态筛选	需理解复杂的状态枚举	提供场景预设，拿来即用
开发时间	至少1天（含授权+解析）	10分钟完成对接

六、总结

通过深圳小于科技的售后订单列表接口，你可以：

• 灵活筛选：按售后类型、售后状态精准过滤，特别适合退货退款场景
• 简化开发：无需处理授权和Token，专注业务逻辑
• 场景预设：提供常用filter组合，复制即用
• 即接即用：无需等待审核，注册立即可用

无论是退货退款自动化、仓库退货入库联动还是超时预警，这个接口都能帮你省时省力，把时间花在更有价值的业务上。

---

特别说明 ：本接口服务由深圳小于科技有限公司(www.szlessthan.com)提供，致力于为中小电商开发者解决抖店、快手等平台接口接入难题。我们提供的不只是接口，更是高效的解决方案。

公司署名 ：深圳小于科技有限公司
官网 ：https://www.szlessthan.com
Slogan：让电商接口，简单如水电。