Ahora puedes gestionar quién tiene acceso a tus sitios de WordPress a través de la API de Kinsta.

Hemos añadido tres endpoints que te permiten consultar los datos de un usuario concreto de la empresa y actualizar sus permisos a nivel de empresa o de sitio. El endpoint ya existente para ver la lista de usuarios de la empresa también ofrece más información sobre el rol de cada persona y el método de autenticación de dos factores (2FA).

Esta actualización también introduce un nuevo ID de referencia que facilita obtener ayuda cuando falla una operación de la API.

Recuperar los usuarios de la empresa con sus roles y los datos de la autenticación de dos factores (2FA)

El endpoint existente Obtener lista de usuarios de la empresa se ha ampliado para que muestre más información sobre cada usuario.

Antes, podías recuperar datos básicos como el nombre del usuario, su dirección de correo electrónico y su imagen de perfil. Ahora, la respuesta incluye un array capabilities que describe los roles del usuario en la empresa y en el sitio, junto con un campo type_2fa que indica su método de autenticación configurado.

Para recuperar los usuarios de tu empresa, envía una solicitud GET:

curl --request GET \
  --url https://api.kinsta.com/v2/company/{company_id}/users \
  --header 'Authorization: Bearer <YOUR_TOKEN_HERE>'

Ahora la respuesta incluye los siguientes campos adicionales:

{
  "company": {
    "users": [
      {
        "user": {
          "id": "54fb80af-576c-4fdc-ba4f-b596c83f15a1",
          "email": "[email protected]",
          "image": "https://www.gravatar.com/avatar/205e460b479e2e5b48aec07710c08d50",
          "full_name": "John Doe",
          "type_2fa": "email"
        },
        "capabilities": [
          {
            "id": "9c1f7b2e-3d4a-4f5b-8c6d-1e2f3a4b5c6d",
            "type": "company",
            "role": "company-admin",
            "company_id": "54fb80af-576c-4fdc-ba4f-b596c83f15a1",
            "site_id": null
          }
        ]
      }
    ]
  }
}

Cada capacidad identifica el rol asignado y la empresa o el sitio asociados. El campo type_2fa puede contener un método de autenticación configurado o null.

Esta información adicional resulta útil a la hora de revisar los permisos de acceso del equipo, comprobar los roles asignados o crear herramientas internas que muestren quién puede acceder a recursos concretos.

Obtener un usuario específico de la empresa por ID

Un nuevo endpoint Obtener un usuario de la empresa por ID te permite recuperar los datos de una persona sin tener que cargar toda la lista de usuarios de la empresa.

Introduce el ID de la empresa y el ID del usuario en la solicitud:

curl --request GET \
  --url https://api.kinsta.com/v2/company/{id}/users/{id_user} \
  --header 'Authorization: Bearer <YOUR_TOKEN_HERE>'

La respuesta incluye la información básica de la persona, el método de 2FA y las capacidades asignadas:

{
  "company": {
    "user_by_id": {
      "user": {
        "id": "9c1e4d2a-1b3c-4f5a-8d6e-7f8a9b0c1d2e",
        "email": "[email protected]",
        "full_name": "John Doe",
        "type_2fa": "email"
      },
      "capabilities": [
        {
          "role": "company-developer",
          "id_company": "54fb80af-576c-4fdc-ba4f-b596c83f15a1",
          "id_site": null
        }
      ]
    }
  }
}

Puedes usar este endpoint para comprobar los permisos actuales de una persona antes de cambiarle el rol o de incluir sus permisos en un informe de acceso interno.

Cambiar el rol de un usuario en la empresa

El nuevo endpoint Editar capacidades de usuario para la empresa te permite cambiar el rol a nivel de empresa de un usuario ya existente.

Admite tres roles:

  • company-admin, que proporciona acceso administrativo en toda la empresa.
  • company-developer, que te da acceso para gestionar sitios y recursos relacionados con el desarrollo, pero sin permisos de facturación.
  • company-billing, que te da acceso a la información de facturación sin poder acceder a los sitios de WordPress.

Por ejemplo, la siguiente solicitud cambia el rol de un usuario ya existente a Desarrollador de la empresa:

curl --request POST \
  --url https://api.kinsta.com/v2/company/{company_id}/users/company-capabilities \
  --header 'Authorization: Bearer <YOUR_TOKEN_HERE>' \
  --header 'Content-Type: application/json' \
  --data '{
    "user_id": "54fb80af-576c-4fdc-ba4f-b596c83f15a1",
    "role": "company-developer"
  }'

Cuando se acepta la solicitud, la respuesta incluye un ID de operación:

{
  "message": "User capabilities updated for the company",
  "status": 202,
  "operation_id": "company:set-company-user-capabilities-54fb80af-576c-4fdc-ba4f-b596c83f15a1"
}

Puedes usar el operation_id devuelto para comprobar el estado de la operación.

Los roles a nivel de empresa determinan a qué recursos puede acceder una persona, por lo que cambiar un rol puede conceder o retirar el acceso a sitios, a la facturación o a la configuración de la empresa. Consulta la documentación sobre roles y permisos de usuario para ver el acceso asociado a cada rol.

Actualizar los permisos de los usuarios en cada sitio web

También puedes gestionar el acceso a nivel de sitio con el nuevo endpoint Editar capacidades de los usuarios del sitio.

A diferencia de los permisos a nivel de empresa, las capacidades del sitio se aplican a sitios específicos de WordPress. Esto resulta útil cuando quieres que un desarrollador o un cliente tenga acceso a un sitio concreto sin concederle acceso a toda la empresa.

El endpoint acepta un array user_ids y un array site_capabilities, por lo que puedes especificar varias asignaciones de usuarios y sitios en una sola solicitud.

Cada asignación de sitio admite dos roles:

  • site-admin, que le da al usuario acceso administrativo al sitio asignado y a sus entornos, sujeto a las restricciones del rol.
  • site-developer, que proporciona acceso a los entornos staging del sitio, con permisos limitados.

Por ejemplo, esta solicitud asigna a un usuario el rol de Desarrollador del sitio:

curl --request POST \
  --url https://api.kinsta.com/v2/company/{company_id}/users/site-capabilities \
  --header 'Authorization: Bearer <YOUR_TOKEN_HERE>' \
  --header 'Content-Type: application/json' \
  --data '{
    "user_ids": [
      "54fb80af-576c-4fdc-ba4f-b596c83f15a1"
    ],
    "site_capabilities": [
      {
        "site_id": "54fb80af-576c-4fdc-ba4f-b596c83f15a1",
        "role": "site-developer"
      }
    ]
  }'

La respuesta incluye un ID de operación que puedes usar para hacer un seguimiento de la actualización:

{
  "message": "Users capabilities updated for the site",
  "status": 202,
  "operation_id": "company:set-site-user-capabilities-54fb80af-576c-4fdc-ba4f-b596c83f15a1"
}

Para los equipos que gestionan varios sitios web de clientes, este endpoint te permite asignar permisos de sitio desde un script de incorporación o un sistema de gestión interno.

Resuelve problemas en las operaciones de la API con un nuevo ID de referencia de soporte

También hemos añadido un campo opcional support_reference_id a las respuestas de los endpoints de la API que activan acciones en MyKinsta.

Anteriormente, estas solicitudes devolvían un operation_id que podías usar para comprobar el progreso de la operación. Sin embargo, como los ID de operación se almacenan temporalmente en caché, puede resultar difícil identificar la acción subyacente al investigar una solicitud fallida.

El nuevo support_reference_id identifica la acción original, lo que ofrece al servicio de soporte de Kinsta una forma más directa de investigar qué ha pasado.

Este campo puede aparecer en la respuesta inicial de la API y al comprobar el estado de la operación a través del endpoint existente Get operation status:

curl --request GET \
  --url https://api.kinsta.com/v2/operations/{operation_id} \
  --header 'Authorization: Bearer <YOUR_TOKEN_HERE>'

Por ejemplo, una operación que aún se está ejecutando puede devolver:

{
  "status": 202,
  "message": "Operation in progress",
  "support_reference_id": 12345,
  "data": null
}

Si una acción de la API falla, puedes facilitar el ID de referencia de soporte a nuestro equipo de soporte para ayudarles a localizar e investigar la acción correspondiente.

Como el campo es opcional, las integraciones deberían seguir usando operation_id para seguir el progreso y conservar support_reference_id cuando esté disponible.

Gestiona el acceso de los usuarios con tus propias herramientas

Estas novedades te permiten crear flujos de trabajo de acceso de usuarios más completos con la API de Kinsta. Puedes consultar los permisos actuales de una persona, cambiar su rol en la empresa o asignar acceso a nivel de sitio sin tener que gestionar cada cambio por separado en el panel de control.

El nuevo ID de referencia de soporte también ofrece a los equipos un identificador útil que pueden conservar a la hora de registrar operaciones de la API e investigar fallos.

Echa un vistazo a los endpoints disponibles y a los formatos de solicitud en la documentación de la API de Kinsta.