Authorization con esquema Bearer. La misma clave autentica todos los endpoints (payment intents, addresses, balances, payouts, etc.).
El SDK del navegador no usa claves — sólo monta UI a partir de un payment_intent_id que tu servidor creó previamente.
Obtener tus claves
- Accede al panel de integración con tu cuenta de organización.
- En la sección de desarrolladores, genera una clave sandbox (
sk_test_...) para pruebas. - Cuando tu organización esté aprobada, genera una clave live (
sk_live_...) para producción.
Formato de las claves
Ejemplo de petición
Cuenta aprobada
Los endpoints que implican movimiento de fondos exigen que tu organización esté activa en Connect. Si aún está enpending_verification o suspended, recibirás HTTP 403 con código account_pending_approval.
Errores de autenticación
El
code es estable; haz match contra él en tu cliente en lugar de parsear message. La diferencia entre authentication_required y expired_credential es deliberada: la primera dice “revisa el header”, la segunda dice “rota la clave”.
Expiración y rotación de claves
Cada clave puede llevar un timestamp opcionalexpires_at (ISO 8601). Cuando se cumple, la API devuelve 401 expired_credential con un mensaje indicando la fecha. Cuando expires_at es null (default para claves legacy o minteadas sin TTL), la clave no expira.
Detectar expiración desde tu cliente
GET /connect/v1/health devuelve key_expires_at:
key_expires_at al arranque y alerta a ops si está dentro de tu ventana de rotación (p. ej. 14 días).