聚合票务软件数据API
各维度得分依据公开资料与字段推算,加权后即综合评分,仅供参考。
SAPITI 是一个“Simple API For Ticketing Systems”，定位为票务系统聚合 API。它希望让开发者通过统一接口访问多个现代票务软件的信息。根据文档，项目仍处于早期阶段，当前首先支持比利时票务软件 UTick，并计划未来增加其他票务平台，同时保持 API 定义稳定。
从功能看，SAPITI 主要覆盖票务业务链路：访问 agenda/events、管理特定合作伙伴的日程、为活动订座，以及通过 Device Id 面向特定合作伙伴读取活动、进行现场访问控制扫描、打印票据。它提供测试环境 https://sapiti.ovh/v1 与正式环境 https://sapiti.net/v1，并有无需鉴权的 /ping/ 用于服务可用性检查。
API 响应结构较规范，统一返回 success、response、environment、api_version、datetime、cached、status_code、language 等字段；错误也有独立 error.code 与 message。文档列出了 200、400、401、403、404、500 等状态码，以及无效 JSON、缺少参数、鉴权失败、ID 不存在等错误码，对开发调试有帮助。
SDK 方面，文档仅明确提供 PHP Library，托管在 GitHub，并支持 Composer 安装：composer require mediamorphosebe/sapiti-client。鉴权采用 public key、timestamp 和基于 private key 的 HMAC-SHA256 signature，timestamp 需在服务器时间 30 秒范围内，安全设计相对明确。生态方面，目前只确认 UTick，其他票务软件尚未列出，因此跨平台价值仍依赖后续扩展。
抓取文本未披露定价模式、免费额度、调用限额、SLA、支付方式或合同支持方式。API 访问需要团队根据用途提供 Application key 或 Device Id，说明接入可能是人工审批制，而非完全自助开通。
优点是接口结构清楚、测试/生产环境分离、错误码明确、PHP 接入方便，适合已有票务业务、需要对接 UTick 或构建活动订座/验票/出票系统的开发团队。缺点是项目早期特征明显：支持平台少，SDK 语言单一，未说明自托管、闭源/开源边界、价格和服务保障，文档也缺少更完整的业务端点示例。
文档未提供中国大陆访问、节点、备案或支付信息，china_access 只能判断为未知。若在中国团队中使用，建议先实测 API 延迟和稳定性，并评估本地票务系统或自建票务 API 作为替代方案。
本测评基于公开资料整理,不构成购买建议,请以 sapiti.net 官网实际信息为准。
早期API项目，适合票务集成开发参考。
评分明细(分布与用户短评)接入中。当前展示 TG4G 综合评分,数据源自公开测评与用户反馈。