Referencia API

API de Facturación

Planes, saldos y estados de crédito

Referencia HTTP. Generada a partir del contrato backend. Explore los endpoints abajo o descargue OpenAPI.

Este grupo tiene 6 operaciones, generadas a partir de api/openapi.yaml. Filtre por ruta, acción o autenticación. Cada endpoint indica sus entradas; despliéguelo para ver una plantilla de solicitud y los códigos de respuesta. Las plantillas necesitan sus propios valores y un cuerpo válido según el esquema.

Reemplace los marcadores en mayúsculas con sus valores. Para una solicitud JSON, guarde un cuerpo que coincida con el esquema en request.json. Los ejemplos de cookies usan un frasco de cookies local de una sesión autenticada.

Planes, saldos y estados de crédito

GET/api/billing/balance

Obtener saldo de facturación

La instantánea del saldo consciente de la fuente del proyecto que llama. Todos los montos en milicréditos son cadenas decimales canónicas. Es una instantánea, no autoridad para pagar; rails_available es falso mientras la tarjeta, impuestos y canal de retiro no estén disponibles.

Autenticación
projectBearer O dashboardSession
Cuerpo de la solicitud
ninguno
ID de operación
getBillingBalance

Parámetros

NombreEnviar¿Requerido?Descripción
ScreenRig-ProjectencabezadoopcionalObsoleto por una versión. Debe ser consistente con las concesiones de proyectos JWT; añade encabezados Deprecation y Warning. Sin intercambio de token.
Plantilla y respuestas de solicitud
shell · plantilla de solicitud
curl --request GET --header 'Authorization: Bearer [SCREENRIG_TOKEN]' --cookie cookies.txt --cookie-jar cookies.txt 'https://screenrig.ai/api/billing/balance'

Respuestas

EstadoSignificadoCuerpo y encabezados
200Instantánea de balance.Saldo de facturación (application/json)
predeterminado

Respuesta estable RFC 9457 a problemas. Un 421 server_draining lleva Retry-After de 1 segundo, un 500 not_ready o dependency_unavailable lleva 5, y un 500 manifest_degraded lleva 60, a menos que el manejador establezca un valor más específico.

Problema (application/problem+json)
GET/api/billing/statement

Obtener estado de cuenta de facturación

Paginación estable con cursor sobre entradas de diario inmutables publicadas para el proyecto que llama. Las retenciones no son entradas publicadas. Las correcciones enlazan al evento original en lugar de reescribirlo. No hay mutación arbitraria de concesión o pago en esta superficie.

Autenticación
projectBearer O dashboardSession
Cuerpo de la solicitud
ninguno
ID de operación
getBillingStatement

Parámetros

NombreEnviar¿Requerido?Descripción
ScreenRig-ProjectencabezadoopcionalObsoleto por una versión. Debe ser consistente con las concesiones de proyectos JWT; añade encabezados Deprecation y Warning. Sin intercambio de token.
cursorconsultaopcional
límiteconsultaopcional
Plantilla y respuestas de solicitud
shell · plantilla de solicitud
curl --request GET --header 'Authorization: Bearer [SCREENRIG_TOKEN]' --cookie cookies.txt --cookie-jar cookies.txt 'https://screenrig.ai/api/billing/statement'

Respuestas

EstadoSignificadoCuerpo y encabezados
200Página de estado de cuenta.Estado de cuenta de facturación (application/json)
400invalid_request - el límite está fuera de rango.Problema (application/problem+json)
predeterminado

Respuesta estable RFC 9457 a problemas. Un 421 server_draining lleva Retry-After de 1 segundo, un 500 not_ready o dependency_unavailable lleva 5, y un 500 manifest_degraded lleva 60, a menos que el manejador establezca un valor más específico.

Problema (application/problem+json)
GET/api/billing/usage

Obtener uso de facturación

El uso del proyecto que llama durante un mes UTC, con los bytes servidos y recibidos (nunca se cobran), el almacenamiento cobrado por encima del almacenamiento gratuito del plan del pagador (allowance.storage_bytes), y las solicitudes de API, los eventos de flujo del proyecto facturados y los intentos de entrega de webhook contados frente a los 10,000 gratuitos al mes. Un proyecto que paga por sí mismo lee su propio fondo.

Un proyecto que otro pagador paga comparte el grupo de ese pagador con los otros proyectos del pagador; lee su propia parte, y payer nombra al pagador. El total del grupo del pagador permanece en las lecturas de facturación del pagador.

Autenticación
projectBearer O dashboardSession
Cuerpo de la solicitud
ninguno
ID de operación
getBillingUsage

Parámetros

NombreEnviar¿Requerido?Descripción
ScreenRig-ProjectencabezadoopcionalObsoleto por una versión. Debe ser consistente con las concesiones de proyectos JWT; añade encabezados Deprecation y Warning. Sin intercambio de token.
periodoconsultaopcionalMes UTC en formato YYYY-MM; por defecto el mes actual.
Plantilla y respuestas de solicitud
shell · plantilla de solicitud
curl --request GET --header 'Authorization: Bearer [SCREENRIG_TOKEN]' --cookie cookies.txt --cookie-jar cookies.txt 'https://screenrig.ai/api/billing/usage'

Respuestas

EstadoSignificadoCuerpo y encabezados
200Uso del proyecto.ProjectBillingUsage (application/json); headers: Cache-Control
400invalid_request - el período no es un mes UTC en formato YYYY-MM.Problema (application/problem+json)
predeterminado

Respuesta estable RFC 9457 a problemas. Un 421 server_draining lleva Retry-After de 1 segundo, un 500 not_ready o dependency_unavailable lleva 5, y un 500 manifest_degraded lleva 60, a menos que el manejador establezca un valor más específico.

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

Obtener oferta de App Store

Lo que una organización puede comprar mediante App Store en la aplicación de screenRIG para iPhone y iPad (bundle ai.screenrig.app), y el token de cuenta que llevan sus compras.

Requiere un administrador designado de la organización activa (la persona que gestiona su plan y su facturación); el personal y los administradores del revendedor en el que está delegada la organización pueden leer la oferta sin products ni token, y cualquier otra persona recibe 404 not_found.

Una organización delegada en un revendedor no lista productos: su revendedor paga su plan. account_token es un UUID aleatorio que el servidor crea una vez por organización y conserva: la aplicación lo pasa a StoreKit como appAccountToken, de modo que cada transacción y cada notificación del servidor nombra a su organización.

Para un lector que no puede comprar, account_token es el UUID de todo ceros. products enumera los planes que quien llama puede comprar ahora, un producto de App Store cada uno: plus, education (solo mientras education_eligible sea true) y premium. education_eligible es true cuando el personal verificó una escuela o un distrito K-12, o cuando el administrador que lee la oferta tiene una dirección de correo de cuenta verificada en un dominio escolar K-12 (education_eligibility_source school_email): abrir la oferta, o registrar una transacción, como ese administrador hace elegible a la organización una vez, escribe una entrada de auditoría de la organización con el dominio coincidente e incluye Education en la misma oferta.

Una decisión del personal, en uno u otro sentido, es definitiva y la elegibilidad automática nunca la anula.

No se ofrece un plan que la organización ya tiene por otra vía (personal, facturación, otra suscripción) en el mismo nivel o en uno superior, salvo a la persona cuya suscripción de App Store lo tiene, que puede cambiar de plan dentro del grupo de suscripciones. can_purchase es true cuando products no está vacío. subscription es la suscripción de App Store de la organización, o null.

La respuesta es privada y no-store.

Autenticación
dashboardSession
Cuerpo de la solicitud
ninguno
ID de operación
getAppStoreOffer

Parámetros

NombreEnviar¿Requerido?Descripción
organization_idrutarequerido
Plantilla y respuestas de solicitud
shell · plantilla de solicitud
curl --request GET --cookie cookies.txt --cookie-jar cookies.txt 'https://screenrig.ai/api/organizations/ORGANIZATION_ID/app-store/offer'

Respuestas

EstadoSignificadoCuerpo y encabezados
200La oferta de planes de App Store de la organización.AppStoreOffer (application/json); encabezados: Cache-Control
predeterminado

Respuesta estable RFC 9457 a problemas. Un 421 server_draining lleva Retry-After de 1 segundo, un 500 not_ready o dependency_unavailable lleva 5, y un 500 manifest_degraded lleva 60, a menos que el manejador establezca un valor más específico.

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

Registrar transacción de App Store

Registra una transacción firmada de StoreKit 2 (Transaction.jwsRepresentation) comprada para la organización y coloca a la organización en su plan. Requiere un administrador designado de la organización activa, autenticación por cookie del mismo origen y, para sesiones JWT, el encabezado CSRF.

El servidor verifica el JWS con su cadena x5c hasta Apple Root CA - G3 (fuera de producción también la raíz de pruebas de StoreKit de Xcode), el bundle id ai.screenrig.app, el id de producto, el entorno (Production solo en producción; Sandbox en todas partes, porque App Review y TestFlight compran con cuentas sandbox contra producción; Xcode solo fuera de producción) y que appAccountToken sea igual al account_token de la organización (getAppStoreOffer); nada en la solicitud nombra quién pagó.

El plan sigue el producto de la transacción más reciente de la suscripción: un plan superior se aplica de inmediato y uno inferior cuando lo alcanza el siguiente límite mensual UTC de la facturación, como en cualquier cambio de plan. Enviar una transacción de nuevo, o una anterior, no cambia nada y responde con la suscripción tal como está; una transacción vencida se registra y no cambia ningún plan.

La aplicación finaliza la transacción tras un 2xx o un problema 4xx definitivo. Problemas: app_store_transaction_invalid (422), app_store_account_mismatch (409), education_not_eligible (403), app_store_plan_conflict (409), billed_by_reseller (409, la organización está delegada en un revendedor, que paga su plan).

Autenticación
dashboardSession
Cuerpo de la solicitud
AppStoreTransactionRequest
ID de operación
recordAppStoreTransaction

Parámetros

NombreEnviar¿Requerido?Descripción
organization_idrutarequerido

Campos del cuerpo de la solicitud

CampoDescripción
signed_transaction (requerido, cadena)La jwsRepresentation de StoreKit 2 de la transacción, exactamente como la devolvió StoreKit. minLength: 1 maxLength: 65536
Plantilla y respuestas de solicitud
shell · plantilla de solicitud
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'

Respuestas

EstadoSignificadoCuerpo y encabezados
200La suscripción de App Store después de la transacción.AppStoreSubscription (application/json); encabezados: Cache-Control
predeterminado

Respuesta estable RFC 9457 a problemas. Un 421 server_draining lleva Retry-After de 1 segundo, un 500 not_ready o dependency_unavailable lleva 5, y un 500 manifest_degraded lleva 60, a menos que el manejador establezca un valor más específico.

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

Recibir notificación de App Store

App Store Server Notifications V2 de Apple (el cuerpo signedPayload), la URL configurada en App Store Connect para los entornos de producción y sandbox. Pública: la carga útil firmada es la credencial, verificada igual que recordAppStoreTransaction verifica una transacción, junto con la transacción firmada y la información de renovación que contiene.

SUBSCRIBED, DID_RENEW, DID_CHANGE_RENEWAL_PREF y DID_CHANGE_RENEWAL_STATUS (y OFFER_REDEEMED, RENEWAL_EXTENDED y REFUND_REVERSED) aplican la transacción más reciente: una renovación amplía la suscripción, una mejora cambia el plan de inmediato y una degradación cuando el producto inferior se renueva al final del periodo.

EXPIRED, GRACE_PERIOD_EXPIRED, REFUND y REVOKE terminan la suscripción y quitan el plan que estableció, como la facturación quita cualquier plan: en el siguiente límite mensual UTC, sin devolver nada ya concedido. Un plan que el personal o la facturación hayan puesto después en la organización nunca se quita.

Cualquier otro tipo, una notificación de un producto que no es un plan y una que no nombra ninguna organización se confirman y se registran. 200 confirma. Una carga útil que no se verifica es un problema 422 app_store_transaction_invalid; un fallo del lado del servidor es un 5xx, que Apple vuelve a enviar. Limitado por dirección de cliente.

Autenticación
ninguno
Cuerpo de la solicitud
AppStoreNotificationRequest
ID de operación
receiveAppStoreNotification

Campos del cuerpo de la solicitud

CampoDescripción
signedPayload (requerido, cadena)Notificación firmada de Apple (un JWS). minLength: 1
Plantilla y respuestas de solicitud
shell · plantilla de solicitud
curl --request POST --header 'Content-Type: application/json' --data '@request.json' 'https://api.screenrig.ai/api/app-store/notifications'

Respuestas

EstadoSignificadoCuerpo y encabezados
200La notificación se confirmó.AppStoreNotificationAcknowledgement (application/json); encabezados: Cache-Control
422app_store_transaction_invalid — la carga útil no es una notificación de App Store válida para este servidor.Problema (application/problem+json)
429

Problema estable rate_limited. Reintente solo después del intervalo Retry-After autorizado. Las denegaciones de ventana fija también incluyen la política RateLimit-Policy y los miembros RateLimit aplicables; las denegaciones por concurrencia y presupuesto de bytes omiten esas divulgaciones opcionales.

Problema (application/problem+json); encabezados: Retry-After, RateLimit-Policy, RateLimit
predeterminado

Respuesta estable RFC 9457 a problemas. Un 421 server_draining lleva Retry-After de 1 segundo, un 500 not_ready o dependency_unavailable lleva 5, y un 500 manifest_degraded lleva 60, a menos que el manejador establezca un valor más específico.

Problema (application/problem+json)