Conceptos
Una aceptación, un deal verificable.
APC-3 convierte una oferta publicada en una aplicación idempotente y conserva snapshots contractuales. El casino provisiona L0/L1 y solo activa cuando existe un mapping operativo no secreto.
Antes de aplicar
Partner
Estado active y membresía owner vigente.
Programa
Programa published dentro de una Casino Landing publicada.
Oferta
Versión publicada, vigente y todavía señalada por el snapshot público.
Lifecycle bilateral
- 01
submitted
El partner aceptó las versiones vigentes y envió la aplicación.
- 02
provisioning
El Casino Admin aprobó y fijó L0 o L1.
- 03
active
Existe un mapping válido y la relación está habilitada.
- 04
suspended
El casino pausó esta relación sin afectar otros deals.
Estados terminales: rejected, cancelled y ended. Una nueva aplicación solo puede comenzar después de que la relación anterior sea terminal.
Superficies privadas
Partner
- GET /partner/programs?casino&offer
- POST /partner/deals
- GET /partner/deals
- GET/PATCH /partner/deals/{deal_id}
Casino
- GET /casino/deals
- GET /casino/deals/{deal_id}
- PATCH /casino/deals/{deal_id}
POST /partner/deals exige Idempotency-Key. Repetir clave y payload devuelve el mismo deal; reutilizarla con otro payload devuelve conflicto.
Permisos
Las acciones vienen del servidor.
Partner owner aplica y cancela submitted. Casino owner transiciona. Casino member ve los deals, pero recibe cero acciones de mutación.
L0 / L1
Solo mappings no secretos.
L0 admite código manual, promo code o affiliate ID. L1 admite sub ID o affiliate ID. Contraseñas, tokens y credenciales de proveedor nunca forman parte del deal.
Fronteras
Activo todavía no significa tracking.
APC-3 no emite links ni recibe eventos. Tracking comienza en APC-4, ingesta en APC-5 y cálculo financiero en APC-6.