指南 · 迁移

从 FASHN 迁移至 Photta 变动之处与保留项

一句话总结

将 try-on 集成迁移至 Photta 意味着更换 Bearer 密钥、新的请求体以及新的状态查询路径。集成的基础架构形态——提交、轮询、下载、存储——保持不变。

  • 常规耗时: 1.5–4 min
  • Credits: 2K 分辨率 5 credits · 4K 分辨率 6 credits
  • 处理方式: 异步,轮询

本页所有数据均来自 Photta API 文档 · 已验证

简要结论

技术团队在不同 try-on API 之间迁移通常出于常见考量:生成效果更契合其商品目录风貌、特定业务量级下的单图综合成本更有优势,或是需要现有供应商未开放的特定能力——例如批量隐形模特、局部细节特写,或在整个季度复用的自建生成模特。

主要涉及三点:凭证、请求体和状态路径。Photta 在每次调用中通过 Bearer 密钥进行身份验证,使用独立的字段命名规范,并通过细分能力的专属状态 endpoint 报告任务进度。代码发送的每个值都以枚举或可预先列出的 ID 形式规范定义。

架构体系。两者均为采用“提交并轮询”模式的异步 API,因此你原有的队列、工作进程、重试策略和存储链路均可继续沿用。在实际工程落地中,迁移本质上是替换一个新的客户端模块和一套字段命名规范,而非重构整套流水线。

你将接入的新 endpoint

直接取自 Photta API 文档,无需手动编写。

概览

端点
POST /api/v1/tryon/apparel
身份验证
Bearer API 密钥
处理方式
异步 — 轮询状态端点
常规耗时
1.5–4 min
Credits
2K 分辨率 5 credits · 4K 分辨率 6 credits
宽高比
3:4 · 1:1 · 4:3 · 9:16 · 16:9
输入限制
单张图片最大 10 MB;支持 JPEG, PNG, WebP
幂等性
否

实际需要变更的 4 个要点

  • 身份验证

    每个 endpoint 仅需一个在 Photta 控制台中创建的 Bearer 密钥。无需针对单个 endpoint 配置权限范围(scope),也无需进行 token 交换。

  • 请求体

    Photta 接收带有文档规范枚举的 snake_case 字段,以及模特、姿势和背景的 ID(这些 ID 可从资源 endpoint 获取并缓存)。

  • 轮询

    每 3 秒轮询一次对应功能的 status endpoint,直至返回 completed 或 failed。无 Webhook 机制,因此无需对外暴露任何新的公网接口。

  • 计费方式

    按调用扣除 credits——服装 try-on 在 2K 分辨率下为 5 credits,4K 为 6 credits。任务启动时扣费,失败时自动退回。

全新请求结构

使用 cURL、Node.js 和 Python 的同等调用示例。

RESPONSE=$(curl -s -X POST https://api.photta.app/api/v1/tryon/apparel \
  -H "Authorization: Bearer $PHOTTA_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
  "product_type": "top",
  "product_images": [
    "https://cdn.yourstore.com/products/shirt-front.jpg"
  ],
  "product_back_image": "https://cdn.yourstore.com/products/shirt-back.jpg",
  "product_category": "t_shirt",
  "mannequin_id": "mnk_f3a9b1",
  "pose_id": "pose_c2d4e5",
  "background": "https://cdn.yourstore.com/backgrounds/studio-loft.jpg",
  "lock_background": true,
  "resolution": "2K",
  "aspect_ratio": "3:4",
  "body_size": "M",
  "expression": "neutral",
  "user_instruction": "Keep the collar pattern crisp and centered."
}')
ID=$(echo "$RESPONSE" | jq -r '.data.id')

迁移常见问题

迁移需要多长时间?

只需修改一个客户端模块:换用新密钥、新字段名和新的 status 路径。如果你的 worker 已经具备提交和轮询逻辑,周边代码完全无需变动。

我需要修改现有的任务队列吗?

不需要。两套 API 均为异步设计,因此无论你目前使用什么——Celery、BullMQ、Inngest 还是 cron 定时任务——整体架构都保持不变,仅需更改任务内部的调用逻辑。

已经生成的图片会怎样?

它们是保存在你自有存储中的文件,不会发生任何改变。迁移只会影响你接下来渲染的内容,绝不会波及已经发布的内容。

价格对比情况如何?

对比页面将 Photta 每次调用的 credit 成本与 FASHN 在其官方定价页面上公布的数据进行了对照,并注明了各项数据的获取日期。哪种更划算完全取决于你的实际用量。

我可以同时运行两套方案吗?

可以,而且这是最稳妥的迁移方式。你可以先将商品目录的一小部分切流到新 endpoint,在实际商品上对比输出效果,然后再迁移剩余部分。

双轨并行,平滑切流

将队列流量的一份副本指向新 endpoint,自行对比生成效果。

  • 1.5–4 min
  • 2K 分辨率 5 credits · 4K 分辨率 6 credits
  • 异步,轮询