Ora puoi gestire chi ha accesso ai tuoi siti WordPress tramite l’API di Kinsta.

Abbiamo aggiunto tre endpoint che permettono di recuperare i dettagli di un utente aziendale specifico e di aggiornare le sue autorizzazioni a livello di azienda o di sito. L’endpoint esistente per elencare gli utenti dell’azienda fornisce ora anche maggiori informazioni sul ruolo di ciascuna persona e sul metodo di autenticazione a due fattori (2FA).

Questa versione introduce anche un nuovo ID di riferimento che rende più facile ottenere assistenza quando un’operazione API fallisce.

Recupera gli utenti dell’azienda con i loro ruoli e i dettagli dell’autenticazione a due fattori (2FA)

L’endpoint esistente Get list of company users è stato ampliato per restituire maggiori informazioni su ciascun utente.

In precedenza, era possibile recuperare dettagli di base come il nome dell’utente, l’indirizzo e-mail e l’immagine del profilo. La risposta ora include un array capabilities che descrive i ruoli aziendali e del sito dell’utente, insieme a un campo type_2fa che indica il metodo di autenticazione configurato.

Per recuperare gli utenti dell’azienda, invia una richiesta GET:

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

La risposta ora include i seguenti campi aggiuntivi:

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

Ogni capability identifica il ruolo assegnato e l’azienda o il sito associato. Il campo type_2fa può contenere un metodo di autenticazione configurato oppure null.

Queste informazioni aggiuntive sono utili per verificare gli accessi del team, controllare i ruoli assegnati o creare strumenti interni che mostrino chi può accedere a risorse specifiche.

Recupera un utente aziendale specifico tramite ID

Un nuovo endpoint Get a company user by ID permette di recuperare i dettagli di una persona senza dover recuperare l’intero elenco degli utenti dell’azienda.

Inserisci l’ID azienda e l’ID utente nella richiesta:

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

La risposta contiene le informazioni di base della persona, il metodo 2FA e le autorizzazioni assegnate:

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

Puoi usare questo endpoint per verificare l’accesso attuale di una persona prima di modificare il suo ruolo o includere le sue autorizzazioni in un report di accesso interno.

Modifica il ruolo aziendale di un utente

Il nuovo endpoint Edit user capabilities for the company permette di modificare il ruolo a livello aziendale di un utente esistente.

Supporta tre ruoli:

  • company-admin, che fornisce accesso amministrativo a livello aziendale.
  • company-developer, che offre l’accesso per gestire i siti e le risorse relative allo sviluppo senza autorizzazioni di fatturazione.
  • company-billing, che offre accesso alle informazioni di fatturazione senza poter accedere ai siti WordPress.

Ad esempio, la seguente richiesta modifica il ruolo di un utente esistente in “Sviluppatore azienda”:

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

Quando la richiesta viene accettata, la risposta include un ID operazione:

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

Puoi usare l’ operation_id restituito per controllare lo stato dell’operazione.

I ruoli a livello aziendale determinano a quali risorse una persona può accedere, quindi cambiare un ruolo può concedere o revocare l’accesso ai siti, alla fatturazione o alle impostazioni aziendali. Consulta la documentazione sui ruoli e le autorizzazioni degli utenti per conoscere l’accesso associato a ciascun ruolo.

Aggiorna le autorizzazioni per gli utenti sui singoli siti

Puoi anche gestire l’accesso a livello di sito con il nuovo endpoint Edit users capabilities for the site.

A differenza delle autorizzazioni a livello aziendale, le autorizzazioni a livello di sito si applicano a specifici siti WordPress. Questo è utile quando vuoi che uno sviluppatore o un cliente abbia accesso a un solo sito senza concedergli l’accesso all’intera azienda.

L’endpoint accetta un array user_ids e un array site_capabilities, così puoi specificare più utenti e assegnazioni di siti in un’unica richiesta.

Ogni assegnazione di sito supporta due ruoli:

  • site-admin, che dà a un utente l’accesso amministrativo al sito assegnato e ai suoi ambienti, nel rispetto delle restrizioni del ruolo.
  • site-developer, che fornisce l’accesso agli ambienti di staging del sito, con autorizzazioni limitate.

Ad esempio, questa richiesta assegna a un utente il ruolo di Sviluppatore del sito:

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 risposta include un ID operazione che puoi usare per tenere traccia dell’aggiornamento:

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

Per i team che gestiscono più siti web dei clienti, questo endpoint ti permette di assegnare le autorizzazioni ai siti da uno script di onboarding o da un sistema di gestione interno.

Risolvi i problemi relativi alle operazioni API con un nuovo ID di riferimento del supporto

Abbiamo anche aggiunto un campo opzionale support_reference_id alle risposte degli endpoint API che attivano azioni in MyKinsta.

In precedenza, queste richieste restituivano un operation_id che potevi usare per controllare lo stato di avanzamento dell’operazione. Tuttavia, poiché gli ID delle operazioni vengono memorizzati temporaneamente nella cache, può essere difficile identificare l’azione sottostante quando si indaga su una richiesta fallita.

Il nuovo support_reference_id identifica l’azione originale, fornendo al Supporto di Kinsta un modo più diretto per capire cosa è successo.

Il campo può comparire nella risposta iniziale dell’API e quando controlli lo stato dell’operazione tramite l’endpoint Get operation status già esistente:

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

Ad esempio, un’operazione ancora in esecuzione può restituire:

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

Se un’azione API fallisce, puoi fornire l’ID di riferimento dell’assistenza al nostro team di supporto per aiutarlo a individuare e analizzare l’azione corrispondente.

Poiché il campo è facoltativo, le integrazioni dovrebbero continuare a utilizzare operation_id per monitorare lo stato di avanzamento e conservare support_reference_id quando disponibile.

Gestisci l’accesso degli utenti tramite i tuoi strumenti

Queste novità permettono di creare flussi di lavoro più completi per l’accesso degli utenti con l’API di Kinsta. Puoi recuperare le autorizzazioni attuali di una persona, modificare il suo ruolo aziendale o assegnare l’accesso a livello di sito senza dover gestire ogni modifica singolarmente nella dashboard.

Il nuovo ID di riferimento dell’assistenza offre inoltre ai team un utile identificatore da conservare durante la registrazione delle operazioni API e l’analisi degli errori.

Scopri gli endpoint disponibili e i formati di richiesta nella documentazione dell’API di Kinsta.