Du kannst jetzt über die Kinsta-API verwalten, wer Zugriff auf deine WordPress-Websites hat.

Wir haben drei Endpunkte hinzugefügt, mit denen du die Details eines bestimmten Unternehmensnutzers abrufen und dessen Berechtigungen auf Unternehmens- oder Websitesebene aktualisieren kannst. Der bereits vorhandene Endpunkt zur Auflistung von Unternehmensnutzern liefert nun auch mehr Informationen zur Rolle der jeweiligen Person und zur Methode der Zwei-Faktor-Authentifizierung (2FA).

Mit diesem Release wird außerdem eine neue Referenz-ID eingeführt, die es einfacher macht, Hilfe zu erhalten, wenn ein API-Vorgang fehlschlägt.

Unternehmensbenutzer mit ihren Rollen und 2FA-Details abrufen

Der bestehende Endpunkt „Liste der Unternehmensnutzer abrufen“ wurde erweitert, um mehr Informationen zu jedem Nutzer zurückzugeben.

Bisher konntest du grundlegende Details wie den Namen, die E-Mail-Adresse und das Profilbild eines Nutzers abrufen. Die Antwort enthält nun ein Array capabilities, das die Unternehmens- und Websitesrollen des Nutzers beschreibt, sowie ein Feld type_2fa, das die konfigurierte Authentifizierungsmethode angibt.

Um die Nutzer deines Unternehmens abzurufen, sende eine GET-Anfrage:

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

Die Antwort enthält nun die folgenden zusätzlichen Felder:

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

Jede Berechtigung identifiziert die zugewiesene Rolle und das zugehörige Unternehmen oder die zugehörige Site. Das Feld type_2fa kann eine konfigurierte Authentifizierungsmethode oder null enthalten.

Diese zusätzlichen Informationen helfen dir dabei, den Zugriff des Teams zu überprüfen, zugewiesene Rollen zu kontrollieren oder interne Tools zu entwickeln, die anzeigen, wer auf bestimmte Ressourcen zugreifen darf.

Einen bestimmten Unternehmensbenutzer anhand der ID abrufen

Über den neuen Endpunkt „Unternehmensbenutzer nach ID abrufen“ kannst du die Details einer einzelnen Person abrufen, ohne die gesamte Liste der Unternehmensbenutzer laden zu müssen.

Übergebe die Unternehmens-ID und die Benutzer-ID in der Anfrage:

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

Die Antwort enthält die grundlegenden Informationen der Person, die 2FA-Methode und die zugewiesenen Berechtigungen:

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

Du kannst diesen Endpunkt nutzen, um den aktuellen Zugriff einer Person zu überprüfen, bevor du ihre Rolle änderst oder ihre Berechtigungen in einen internen Zugriffsbericht aufnimmst.

Die Unternehmensrolle eines Benutzers ändern

Über den neuen Endpunkt „Benutzerberechtigungen für das Unternehmen bearbeiten“ kannst du die Rolle eines bestehenden Benutzers auf Unternehmensebene ändern.

Er unterstützt drei Rollen:

  • company-admin, die unternehmensweiten Administratorzugriff gewährt.
  • company-developer, die Zugriff auf die Verwaltung von Websites und entwicklungsbezogenen Ressourcen ohne Abrechnungsberechtigungen gewährt.
  • company-billing, die Zugriff auf Abrechnungsinformationen ohne Zugriff auf WordPress-Websites gewährt.

Beispielsweise ändert die folgende Anfrage die Rolle eines bestehenden Benutzers in „Unternehmensentwickler“:

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

Wenn die Anfrage akzeptiert wird, enthält die Antwort eine Vorgangs-ID:

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

Du kannst die zurückgegebene operation_id verwenden, um den Status des Vorgangs zu überprüfen.

Rollen auf Unternehmensebene legen fest, auf welche Ressourcen eine Person zugreifen kann. Daher kann das Ändern einer Rolle den Zugriff auf Websites, die Abrechnung oder Unternehmenseinstellungen gewähren oder entziehen. Sieh dir die Dokumentation zu Benutzerrollen und Berechtigungen an, um zu erfahren, welche Zugriffsrechte mit den einzelnen Rollen verbunden sind.

Berechtigungen für Benutzer auf einzelnen Websites aktualisieren

Du kannst den Zugriff auf Website-Ebene auch über die neuen Funktionen zum Bearbeiten von Benutzern für den Website-Endpunkt verwalten.

Im Gegensatz zu Berechtigungen auf Unternehmensebene gelten Website-Berechtigungen für bestimmte WordPress-Websites. Das ist nützlich, wenn du einem Entwickler oder Kunden Zugriff auf eine bestimmte Website gewähren möchtest, ohne ihm Zugriff auf das gesamte Unternehmen zu gewähren.

Der Endpunkt akzeptiert ein Array user_ids und ein Array site_capabilities, sodass du in einer einzigen Anfrage mehrere Benutzer und Website-Zuweisungen angeben kannst.

Jede Website-Zuweisung unterstützt zwei Rollen:

  • site-admin, die einem Benutzer administrativen Zugriff auf die zugewiesene Website und ihre Umgebungen gewährt, vorbehaltlich der Einschränkungen der Rolle.
  • site-developer, die Zugriff auf die Staging-Umgebungen der Site mit eingeschränkten Berechtigungen gewährt.

Diese Anfrage weist einem Benutzer beispielsweise die Rolle „Site Developer“ zu:

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

Die Antwort enthält eine Vorgangs-ID, mit der sich die Änderung nachverfolgen lässt:

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

Für Teams, die mehrere Kundenwebsites verwalten, ermöglicht dieser Endpunkt die Zuweisung von Website-Berechtigungen über ein Onboarding-Skript oder ein internes Verwaltungssystem.

Fehlerbehebung bei API-Vorgängen mit einer neuen Support-Referenz-ID

Wir haben außerdem ein optionales Feld support_reference_id zu den Antworten von API-Endpunkten hinzugefügt, die Aktionen in MyKinsta auslösen.

Bisher lieferten diese Anfragen eine operation_id, mit der du den Fortschritt des Vorgangs überprüfen konntest. Da Vorgangs-IDs jedoch vorübergehend zwischengespeichert werden, kann es schwierig sein, die zugrunde liegende Aktion zu identifizieren, wenn du eine fehlgeschlagene Anfrage untersuchst.

Die neue support_reference_id identifiziert die ursprüngliche Aktion und bietet dem Kinsta-Support so eine direktere Möglichkeit, zu untersuchen, was passiert ist.

Das Feld kann in der ursprünglichen API-Antwort erscheinen und bei der Überprüfung des Vorgangs über den bestehenden Endpunkt „Betriebsstatus abrufen“:

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

Beispielsweise kann ein noch laufender Vorgang Folgendes zurückgeben:

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

Wenn eine API-Aktion fehlschlägt, kannst du unserem Support-Team die Support-Referenz-ID mitteilen, damit es die entsprechende Aktion leichter finden und untersuchen kann.

Da das Feld optional ist, sollten Integrationen weiterhin operation_id zur Fortschrittsverfolgung verwenden und support_reference_id beibehalten, sofern verfügbar.

Verwalte den Benutzerzugriff über deine eigenen Tools

Mit diesen Neuerungen kannst du mit der Kinsta-API umfassendere Workflows für den Benutzerzugriff erstellen. Du kannst die aktuellen Berechtigungen einer Person abrufen, ihre Rolle im Unternehmen ändern oder Zugriff auf Website-Ebene zuweisen, ohne jede Änderung einzeln im Dashboard vornehmen zu müssen.

Die neue Support-Referenz-ID bietet Teams zudem eine nützliche Kennung, die sie bei der Protokollierung von API-Vorgängen und der Untersuchung von Fehlern festhalten können.

Entdecke die verfügbaren Endpunkte und Anforderungsformate in der Kinsta-API-Dokumentation.