Download the PHP package pimia/pimia-php without Composer

pimia/pimia-php

baseUrl es el origen, sin /api ni barra final: https://pimia.es para el cliente central o https://acme.pimia.es para el de instancia. El cliente añade /api/… (central, TypeScript) o /api/v1/… (instancia). Desde 0.30.1, un valor terminado en /api o /api/v1 se rechaza al construir el cliente (en PHP, al crear Config), antes de hacer peticiones. Quita ese sufijo; no se elimina automáticamente. Una barra final sigue admitiéndose.

Cliente PHP oficial de la API de Pimia para apps de partner: OAuth con PKCE, rotación del refresh token persistida, reintentos de rate limit y excepciones tipadas. Licencia MIT.

El código vive en el monorepo Pimia-AI/pimia-sdks, directorio php/. Pimia-AI/pimia-php es un espejo de solo lectura que se regenera en cada release: existe porque Composer exige el composer.json en la raíz del repositorio. Las incidencias y los PRs, al monorepo.

Requisitos: PHP ≥ 8.2 + un cliente HTTP PSR-18 (cualquiera vale; Guzzle es el sugerido).

Instalación

Publicado en Packagist desde v0.1.0. Requiere PHP ≥ 8.2 y un cliente HTTP PSR-18 (Guzzle es el sugerido):

Uso en 20 líneas

Lo único que tienes que leer antes de escribir código

El refresh token de Pimia rota. Cada refresco devuelve uno nuevo y mata el anterior; reusar uno ya rotado revoca el grant entero en cascada. Por eso el cliente exige un TokenStore: persiste el conjunto de tokens tras cada refresco y no refresques dos veces en paralelo con el mismo token. Las dos cosas las cubre el SDK si lo usas como está pensado.

Un servicio que reenvía el token de su usuario

Todo lo de arriba supone que tu app posee un grant. Hay integraciones que no y que no deben: un servicio al que el front le manda, en cada petición, el Authorization del usuario que ya entró en Pimia. Para ésas está el modo de token prestado — sin clientId, sin TokenStore y sin ceremonia OAuth:

Lo que ganas con esto es que Pimia sigue decidiendo los permisos: tu servicio no puede darle a nadie más de lo que su token ya le daba, y no hay una credencial de servicio que auditar aparte.

Tres cosas que conviene tener claras:

• Un cliente por petición. El token vive lo que viva la petición que lo trajo; una instancia compartida es una credencial compartida.
• No se refresca. El refresh es del dueño del grant. Cuando el token caduca, el 401 sube como UnauthorizedException y quien tiene que conseguir otro es quien te lo prestó. El cliente no lo intenta —y eso es deliberado: con la rotación de Pimia, tocar el refresh de otro revoca su grant entero.
• $pimia->oauth es null en este modo. No hay ceremonia que hacer, y un OAuthClient sin clientId compondría una URL de autorización rota que sólo fallaría en el navegador del usuario.

GET /bootstrap merece un aviso propio: es la única respuesta del API que no viene envuelta en data. Sus claves cuelgan de la raíz, así que un desenvolvedor de data escrito «para todas las llamadas» devuelve vacío sin error — y el fallo se ve como una empresa sin resolver o como una moneda que cae al respaldo, nunca como un fallo. $pimia->bootstrap->currentCompanyId() y ->currency() lo leen bien; ->get() te da el cuerpo tal cual.

La suscripción del cliente en el Stripe de su integrador

Si tu vertical cobra con tu Stripe, el perfil del cliente puede enseñar su plan y mandarle al portal de Stripe (scopes Scopes::INTEGRADOR_BILLING_READ y Scopes::INTEGRADOR_BILLING_WRITE; dueño o administrador de la empresa):

Los cortes llegan en code del cuerpo (ApiException::$body): suscripcion_no_disponible (404), suscripcion_de_baja (409), return_url_no_permitida (422)… No hay cancel ni changePlan: todo pasa por el portal.

Reintentar un POST sin duplicar

Manda una Idempotency-Key única por operación y Pimia ejecuta la escritura una sola vez, por muchos reintentos que haya:

Reúsala solo en los reintentos de esa misma operación: la misma clave con otro cuerpo responde 422.

Tras un reintento el cuerpo que recibes es idéntico al de la primera llamada —ese es justo el contrato—, así que el cuerpo solo no dice si Pimia escribió o se limitó a repetirse. Para saberlo, requestWithMeta():

Recibir webhooks

WebhookVerifier comprueba la firma PIMIA-WEBHOOK-v1 y te devuelve la entrega ya parseada. No reimplementes el HMAC:

Los ocho eventos del catálogo están en el enum WebhookEvent y sus payloads documentados como array shapes (PHPStan y Psalm los entienden). Un evento que este SDK todavía no conozca no es un error: se verifica igual y llega con $hook->event === null y el nombre crudo en $hook->eventName.

Detalles que ahorran un rato:

• El constructor acepta una lista de secretos, para rotarlo sin ventana de caída.
• La ventana anti-replay son 300 s; ajústala con toleranceSeconds:.
• $e->reason es legible por máquina (signature_mismatch, timestamp_out_of_window, missing_headers, invalid_timestamp, invalid_json) para tus métricas.
• WebhookVerifier::sign() firma un cuerpo como lo haría Pimia: úsalo en tus tests, no en producción.

Más

Documentación completa, modelo mental (un tenant = una base URL = un token), tabla de excepciones tipadas y el contrato OpenAPI, en el monorepo: Pimia-AI/pimia-sdks.

Confirmación del dueño (0.30.0 preparada)

Usuarios administradores, roles admin y vínculos pueden quedar pendientes:

post, put, delete y request conservan el cuerpo 202; no lo convierten al recurso creado. requestWithMeta permite leer además $result->meta->status. El 503 no se reintenta: llega como ApiException, cuyo $e->body['code'] es OwnerConfirmationRequired::MAIL_FAILED_CODE. El SDK no ejecuta ni abre el enlace de confirmación. El plano central y los métodos de primer periodo siguen siendo exclusivos de TypeScript.