Vous pouvez désormais gérer les personnes ayant accès à vos sites WordPress via l’API Kinsta.

Nous avons ajouté trois points de terminaison qui vous permettent de récupérer les informations d’un utilisateur spécifique de l’entreprise et de mettre à jour ses autorisations au niveau de l’entreprise ou du site. Le point de terminaison existant permettant de répertorier les utilisateurs de l’entreprise fournit désormais davantage d’informations sur le rôle de chaque personne et sur la méthode d’authentification à deux facteurs (2FA) utilisée.

Cette mise à jour introduit également un nouvel identifiant de référence qui facilite l’obtention d’aide en cas d’échec d’une opération API.

Récupérer les utilisateurs de l’entreprise avec leurs rôles et leurs informations d’authentification à deux facteurs

Le point de terminaison existant « Get list of company users » a été étendu afin de fournir davantage d’informations sur chaque utilisateur.

Auparavant, vous pouviez récupérer des informations de base telles que le nom de l’utilisateur, son adresse e-mail et son image de profil. La réponse inclut désormais un tableau capabilities décrivant les rôles de l’utilisateur au sein de l’entreprise et sur le site, ainsi qu’un champ type_2fa indiquant sa méthode d’authentification configurée.

Pour récupérer les utilisateurs de votre entreprise, envoyez une requête GET :

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

La réponse comprend désormais les champs supplémentaires suivants :

{
  "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
          }
        ]
      }
    ]
  }
}

Chaque capacité identifie le rôle attribué ainsi que l’entreprise ou le site associé. Le champ type_2fa peut contenir une méthode d’authentification configurée ou null.

Ces informations supplémentaires sont utiles pour examiner les droits d’accès de l’équipe, vérifier les rôles attribués ou développer des outils internes permettant de déterminer qui peut accéder à des ressources spécifiques.

Récupérer un utilisateur d’entreprise spécifique par ID

Un nouveau point de terminaison « Récupérer un utilisateur de l’entreprise par ID » vous permet de récupérer les informations d’une personne sans avoir à extraire la liste complète des utilisateurs de l’entreprise.

Transmettez l’ID de l’entreprise et l’ID de l’utilisateur dans la requête :

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

La réponse contient les informations de base de la personne, sa méthode d’authentification à deux facteurs (2FA) et les capacités qui lui sont attribuées :

{
  "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
        }
      ]
    }
  }
}

Vous pouvez utiliser ce point de terminaison pour vérifier les droits d’accès actuels d’une personne avant de modifier son rôle ou d’inclure ses autorisations dans un rapport d’accès interne.

Changer le rôle d’un utilisateur au sein de l’entreprise

Le nouveau point de terminaison « Changer les autorisations d’un utilisateur au sein de l’entreprise » vous permet de modifier le rôle d’un utilisateur existant au niveau de l’entreprise.

Il prend en charge trois rôles :

  • company-admin, qui offre un accès administratif à l’échelle de l’entreprise.
  • company-developer, qui donne accès à la gestion des sites et des ressources liées au développement, sans autorisations de facturation.
  • company-billing, qui donne accès aux informations de facturation sans accès aux sites WordPress.

Par exemple, la requête suivante modifie le rôle d’un utilisateur existant pour le faire passer à « Développeur de l’entreprise » :

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"
  }'

Lorsque la requête est acceptée, la réponse comprend un identifiant d’opération :

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

Vous pouvez utiliser l’operation_id renvoyé pour vérifier l’état de l’opération.

Les rôles au niveau de l’entreprise déterminent les ressources auxquelles une personne peut accéder ; par conséquent, la modification d’un rôle peut accorder ou supprimer l’accès aux sites, à la facturation ou aux réglages de l’entreprise. Consultez la documentation relative aux rôles et autorisations des utilisateurs pour connaitre les droits d’accès associés à chaque rôle.

Mettre à jour les autorisations des utilisateurs sur des sites individuels

Vous pouvez également gérer les accès au niveau des sites grâce à la nouvelle fonctionnalité « Changer les utilisateurs » du point de terminaison du site.

Contrairement aux autorisations au niveau de l’entreprise, les autorisations au niveau des sites s’appliquent à des sites WordPress spécifiques. Cela s’avère utile lorsque vous souhaitez qu’un développeur ou un client ait accès à un site sans lui accorder l’accès à l’ensemble de l’entreprise.

Le point de terminaison accepte un tableau « user_ids » et un tableau « site_capabilities », ce qui vous permet de spécifier plusieurs utilisateurs et affectations de sites en une seule requête.

Chaque affectation de site prend en charge deux rôles :

  • site-admin, qui confère à un utilisateur un accès administratif au site attribué et à ses environnements, sous réserve des restrictions propres à ce rôle.
  • site-developer, qui donne accès aux environnements de staging du site, avec des autorisations limitées.

Par exemple, cette requête attribue à un utilisateur le rôle de « Développeur du site » :

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 réponse comprend un identifiant d’opération qui peut être utilisé pour suivre la mise à jour :

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

Pour les équipes gérant plusieurs sites web clients, ce point de terminaison vous permet d’attribuer des autorisations de site à partir d’un script d’intégration ou d’un système de gestion interne.

Dépannage des opérations API grâce à un nouvel identifiant de référence d’assistance

Nous avons également ajouté un champ facultatif « support_reference_id » aux réponses des points de terminaison API qui déclenchent des actions dans MyKinsta.

Auparavant, ces requêtes renvoyaient un « operation_id » que vous pouviez utiliser pour vérifier la progression de l’opération. Cependant, comme les identifiants d’opération sont temporairement mis en cache, il peut s’avérer difficile d’identifier l’action sous-jacente lors de l’analyse d’une requête ayant échoué.

Le nouvel identifiant d’support_reference_id permet d’identifier l’action d’origine, offrant ainsi au support Kinsta un moyen plus direct d’analyser ce qui s’est passé.

Ce champ peut apparaitre dans la réponse API initiale et lors de la vérification de l’opération via le point de terminaison existant « Get operation status » :

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

Par exemple, une opération encore en cours d’exécution peut renvoyer :

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

Si une action API échoue, vous pouvez fournir l’identifiant de référence d’assistance à notre équipe de support afin de l’aider à localiser et à analyser l’action correspondante.

Ce champ étant facultatif, les intégrations doivent continuer à utiliser operation_id pour suivre la progression et conserver support_reference_id lorsqu’il est disponible.

Gérez les accès des utilisateurs via vos propres outils

Ces ajouts vous permettent de mettre en place des workflows d’accès utilisateur plus complets grâce à l’API Kinsta. Vous pouvez récupérer les autorisations actuelles d’une personne, modifier son rôle au sein de l’entreprise ou attribuer un accès au niveau du site sans avoir à gérer chaque modification individuellement dans le tableau de bord.

Le nouvel identifiant de référence de support fournit également aux équipes un identifiant utile à conserver lors de la journalisation des opérations API et de l’analyse des défaillances.

Découvrez les points de terminaison et les formats de requête disponibles dans la documentation de l’API Kinsta.