API 参考

计费 API

套餐、额度余额及账单

HTTP 参考。 由后端契约生成。浏览以下端点或下载 OpenAPI。

此分组有 6 个操作,由 api/openapi.yaml 生成。可按路径、操作或认证筛选。每个端点都会列出其输入;展开后可查看请求模板和响应代码。模板需要您自己的值和符合架构的请求体。

用你的值替换大写占位符。对于JSON请求,请保存符合request.json模式的请求体。Cookie示例使用经过身份验证会话的本地Cookie存储。

套餐、额度余额及账单

GET/api/billing/balance

获取账单余额

调用项目的源感知余额快照。所有毫额度数均为规范十进制字符串。它是快照,不是支付授权;当信用卡、税务和提现通道不可用时,rails_available 为 false。

身份验证
projectBearer 或 dashboardSession
请求主体
无
操作 ID
getBillingBalance

参数

名称发送必需?描述
ScreenRig-Projectheader可选已弃用一个版本。必须与 JWT 项目授权保持一致;添加弃用和警告头。无令牌交换。
请求模板和响应
shell · 请求模板
curl --request GET --header 'Authorization: Bearer [SCREENRIG_TOKEN]' --cookie cookies.txt --cookie-jar cookies.txt 'https://screenrig.ai/api/billing/balance'

响应

状态含义正文和头部
200余额快照。BillingBalance(application/json)
默认

稳定的 RFC 9457 问题响应。421 server_draining 携带 1 秒的 Retry-After,500 not_ready 或 dependency_unavailable 携带 5 秒,500 manifest_degraded 携带 60 秒,除非处理程序设置了更具体的值。

问题 (application/problem+json)
GET/api/billing/statement

获取账单明细

针对调用项目的不可变已发布日志条目的稳定游标分页。保留的不是已发布条目。更正链接到原始事件,而非重写。此表面无任意授权或支付变更。

身份验证
projectBearer 或 dashboardSession
请求主体
无
操作 ID
getBillingStatement

参数

名称发送必需?描述
ScreenRig-Projectheader可选已弃用一个版本。必须与 JWT 项目授权保持一致;添加弃用和警告头。无令牌交换。
游标查询可选
限制查询可选
请求模板和响应
shell · 请求模板
curl --request GET --header 'Authorization: Bearer [SCREENRIG_TOKEN]' --cookie cookies.txt --cookie-jar cookies.txt 'https://screenrig.ai/api/billing/statement'

响应

状态含义正文和头部
200对账单页面。BillingStatement(application/json)
400invalid_request - 限制超出范围。问题 (application/problem+json)
默认

稳定的 RFC 9457 问题响应。421 server_draining 携带 1 秒的 Retry-After,500 not_ready 或 dependency_unavailable 携带 5 秒,500 manifest_degraded 携带 60 秒,除非处理程序设置了更具体的值。

问题 (application/problem+json)
GET/api/billing/usage

获取账单使用情况

调用项目在一个 UTC 月内的使用情况,包括已提供和已接收的字节(从不计费)、超出付款方套餐免费存储部分所计费的存储(allowance.storage_bytes),以及计入每月 10,000 次免费额度的 API 请求、计费的项目流事件和 webhook 投递尝试。自行付款的项目读取其自己的池。

另一付款方支付的项目共享该付款方与其其他项目的资金池;项目读取自身份额,付款方标识付款方。付款方资金池总额保留在付款方账单读取中。

身份验证
projectBearer 或 dashboardSession
请求主体
无
操作 ID
getBillingUsage

参数

名称发送必需?描述
ScreenRig-Projectheader可选已弃用一个版本。必须与 JWT 项目授权保持一致;添加弃用和警告头。无令牌交换。
周期查询可选以YYYY-MM格式表示的UTC月份;默认为当前月份。
请求模板和响应
shell · 请求模板
curl --request GET --header 'Authorization: Bearer [SCREENRIG_TOKEN]' --cookie cookies.txt --cookie-jar cookies.txt 'https://screenrig.ai/api/billing/usage'

响应

状态含义正文和头部
200项目用量。ProjectBillingUsage(application/json);头部:Cache-Control
400invalid_request - 周期不是 YYYY-MM 格式的 UTC 月份。问题 (application/problem+json)
默认

稳定的 RFC 9457 问题响应。421 server_draining 携带 1 秒的 Retry-After,500 not_ready 或 dependency_unavailable 携带 5 秒,500 manifest_degraded 携带 60 秒,除非处理程序设置了更具体的值。

问题 (application/problem+json)
GET/api/organizations/{organization_id}/app-store/offer

获取 App Store 购买选项

组织可通过 screenRIG iPhone 和 iPad 应用(bundle ai.screenrig.app)在 App Store 购买的内容,以及其购买所带的账户令牌。

需要有效组织的指定管理员(管理其套餐和账单的人);员工以及该组织所委托经销商的管理员可以读取不含 products 或令牌的购买选项,其他任何人都会收到 404 not_found。

委托给经销商的组织不列出任何 products:其套餐由经销商支付。account_token 是服务器为每个组织创建一次并保存的随机 UUID:应用把它作为 appAccountToken 传给 StoreKit,因此每笔交易和每条服务器通知都会指明其所属组织。

对于无法购买的读取者,account_token 是全零 UUID。products 列出调用方现在可以购买的套餐,每个对应一个 App Store 产品:plus、education(仅当 education_eligible 为 true 时)和 premium。当员工已验证某所 K-12 学校或学区,或者查看该报价的管理员拥有 K-12 学校域名下已验证的账户邮箱地址时(education_eligibility_source 为 school_email),education_eligible 为 true:这类管理员打开报价或记录交易,会使该组织获得一次资格,写入一条注明匹配域名的组织审计条目,并在同一报价中包含 Education。

员工的决定无论结果如何都是最终的,自动资格判定永远不会覆盖它。

如果组织已通过其他来源(员工、开具发票、其他订阅)拥有同级或更高级别的套餐,则不再提供该套餐,但持有该套餐的 App Store 订阅所属的人员除外,该人员可在订阅组内更换套餐。products 不为空时 can_purchase 为 true。subscription 是组织的 App Store 订阅,或 null。

响应为 private 且 no-store。

身份验证
dashboardSession
请求主体
无
操作 ID
getAppStoreOffer

参数

名称发送必需?描述
organization_id路径必填
请求模板和响应
shell · 请求模板
curl --request GET --cookie cookies.txt --cookie-jar cookies.txt 'https://screenrig.ai/api/organizations/ORGANIZATION_ID/app-store/offer'

响应

状态含义正文和头部
200组织的 App Store 套餐购买选项。AppStoreOffer(application/json);头信息:Cache-Control
默认

稳定的 RFC 9457 问题响应。421 server_draining 携带 1 秒的 Retry-After,500 not_ready 或 dependency_unavailable 携带 5 秒,500 manifest_degraded 携带 60 秒,除非处理程序设置了更具体的值。

问题 (application/problem+json)
POST/api/organizations/{organization_id}/app-store/transactions

记录 App Store 交易

记录一笔为组织购买的 StoreKit 2 签名交易(Transaction.jwsRepresentation),并把组织设置到其套餐。需要有效组织的指定管理员、同源的 Cookie 身份验证,对于 JWT 会话还需要 CSRF 标头。

服务器会验证 JWS 的 x5c 证书链直至 Apple Root CA - G3(非生产环境还包括 Xcode 的 StoreKit 测试根证书)、bundle id ai.screenrig.app、产品 id、环境(Production 仅限生产;Sandbox 到处可用,因为 App Review 和 TestFlight 会用沙盒账户对生产环境购买;Xcode 仅限非生产),以及 appAccountToken 是否等于组织的 account_token(getAppStoreOffer);请求中没有任何内容指明谁付了款。

套餐跟随订阅最新交易所对应的产品:更高的套餐立即生效,更低的套餐在账单的下一个 UTC 月边界到来时生效,与任何套餐更改相同。再次发送某笔交易或更早的交易不会有任何改变,并按订阅的当前状态响应;已过期的交易会被记录,但不会改变任何套餐。

应用在收到 2xx 或明确的 4xx 问题后完成该交易。问题:app_store_transaction_invalid(422)、app_store_account_mismatch(409)、education_not_eligible(403)、app_store_plan_conflict(409)、billed_by_reseller(409,组织已委托给经销商,由经销商支付其套餐)。

身份验证
dashboardSession
请求主体
AppStoreTransactionRequest
操作 ID
recordAppStoreTransaction

参数

名称发送必需?描述
organization_id路径必填

请求主体字段

字段描述
signed_transaction(必填,字符串)该交易的 StoreKit 2 jwsRepresentation,与 StoreKit 返回的完全一致。minLength:1 maxLength:65536
请求模板和响应
shell · 请求模板
curl --request POST --cookie cookies.txt --cookie-jar cookies.txt --header 'Content-Type: application/json' --data '@request.json' 'https://screenrig.ai/api/organizations/ORGANIZATION_ID/app-store/transactions'

响应

状态含义正文和头部
200交易后的 App Store 订阅。AppStoreSubscription(application/json);头信息:Cache-Control
默认

稳定的 RFC 9457 问题响应。421 server_draining 携带 1 秒的 Retry-After,500 not_ready 或 dependency_unavailable 携带 5 秒,500 manifest_degraded 携带 60 秒,除非处理程序设置了更具体的值。

问题 (application/problem+json)
POST/api/app-store/notifications

接收 App Store 通知

Apple 的 App Store Server Notifications V2(signedPayload 请求体),即在 App Store Connect 中为生产和沙盒环境设置的 URL。公开:签名载荷就是凭证,其验证方式与 recordAppStoreTransaction 验证交易相同,并连同其中的签名交易和续订信息一并验证。

SUBSCRIBED、DID_RENEW、DID_CHANGE_RENEWAL_PREF 和 DID_CHANGE_RENEWAL_STATUS(以及 OFFER_REDEEMED、RENEWAL_EXTENDED 和 REFUND_REVERSED)会应用最新的交易:续订会延长订阅,升级会立即更改套餐,降级则在较低的产品于周期结束时续订后生效。

EXPIRED、GRACE_PERIOD_EXPIRED、REFUND 和 REVOKE 会结束订阅并移除其设置的套餐,与账单移除任何套餐的方式相同:在下一个 UTC 月边界,已授予的内容不会收回。此后由员工或发票为组织设置的套餐永远不会被移除。

任何其他类型、针对非套餐产品的通知,以及未指明组织的通知,都会被确认并记录。200 表示确认。无法验证的载荷是 422 app_store_transaction_invalid 问题;服务器端故障是 5xx,Apple 会重新发送。按客户端地址限速。

身份验证
无
请求主体
AppStoreNotificationRequest
操作 ID
receiveAppStoreNotification

请求主体字段

字段描述
signedPayload(必填,字符串)Apple 的签名通知(JWS)。minLength:1
请求模板和响应
shell · 请求模板
curl --request POST --header 'Content-Type: application/json' --data '@request.json' 'https://api.screenrig.ai/api/app-store/notifications'

响应

状态含义正文和头部
200通知已确认。AppStoreNotificationAcknowledgement(application/json);头信息:Cache-Control
422app_store_transaction_invalid — 该载荷不是适用于此服务器的有效 App Store 通知。问题 (application/problem+json)
429

稳定的 rate_limited 问题。仅在权威 Retry-After 间隔后重试。固定窗口拒绝还包括适用的 RateLimit-Policy 和 RateLimit 成员;并发和字节预算拒绝省略这些可选披露。

问题 (application/problem+json);头部:Retry-After,RateLimit-Policy,RateLimit
默认

稳定的 RFC 9457 问题响应。421 server_draining 携带 1 秒的 Retry-After,500 not_ready 或 dependency_unavailable 携带 5 秒,500 manifest_degraded 携带 60 秒,除非处理程序设置了更具体的值。

问题 (application/problem+json)