Je kunt nu via de Kinsta API beheren wie toegang heeft tot je WordPress sites.
We hebben drie endpoints toegevoegd waarmee je de gegevens van een specifieke bedrijfsgebruiker opvraagt en de rechten op bedrijfs- of siteniveau aanpast. Het bestaande endpoint waarmee je bedrijfsgebruikers opvraagt, geeft nu ook meer informatie over ieders rol en methode voor tweefactorauthenticatie (2FA).
Ook is er een nieuwe referentie-ID, zodat je makkelijker hulp krijgt als een API-bewerking mislukt.
Bedrijfsgebruikers ophalen met hun rollen en 2FA-gegevens
Het bestaande endpoint Get list of company users geeft nu meer informatie over elke gebruiker.
Voorheen kon je basisgegevens ophalen, zoals de naam, het e-mailadres en de profielfoto van een gebruiker. Het antwoord bevat nu ook een capabilities-array met de bedrijfs- en siterollen van de gebruiker, plus een veld type_2fa dat de ingestelde authenticatiemethode aangeeft.
Om de gebruikers van je bedrijf op te halen, stuur je een GET-request:
curl --request GET \
--url https://api.kinsta.com/v2/company/{company_id}/users \
--header 'Authorization: Bearer <YOUR_TOKEN_HERE>'Het antwoord bevat nu de volgende extra velden:
{
"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
}
]
}
]
}
}Elke bevoegdheid geeft de toegewezen rol aan, en het bijbehorende bedrijf of de bijbehorende site. Het veld type_2fa kan een ingestelde authenticatiemethode bevatten of null.
Die extra informatie is handig als je teamtoegang controleert, toegewezen rollen nakijkt of interne tools bouwt die laten zien wie toegang heeft tot bepaalde bronnen.
Een specifieke bedrijfsgebruiker ophalen op ID
Met het nieuwe endpoint Get a company user by ID haal je de gegevens van één persoon op, zonder de hele lijst met bedrijfsgebruikers op te vragen.
Geef in de request de bedrijfs-ID en de gebruikers-ID mee:
curl --request GET \
--url https://api.kinsta.com/v2/company/{id}/users/{id_user} \
--header 'Authorization: Bearer <YOUR_TOKEN_HERE>'Het antwoord bevat de basisgegevens van de persoon, de 2FA-methode en de toegewezen bevoegdheden:
{
"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
}
]
}
}
}Met dit endpoint controleer je iemands huidige toegang voordat je de rol wijzigt, of voordat je de rechten opneemt in een intern toegangsrapport.
De bedrijfsrol van een gebruiker wijzigen
Met het nieuwe endpoint Edit user capabilities for the company wijzig je de rol op bedrijfsniveau van een bestaande gebruiker.
Er zijn drie rollen beschikbaar:
company-admin, voor beheerderstoegang tot het hele bedrijf.company-developer, voor het beheer van sites en ontwikkelgerelateerde bronnen, zonder rechten voor facturering.company-billing, voor toegang tot factuurgegevens, zonder toegang tot WordPress sites.
Deze request wijzigt bijvoorbeeld de rol van een bestaande gebruiker in Company Developer:
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"
}'Wordt de request geaccepteerd, dan bevat het antwoord een bewerkings-ID:
{
"message": "User capabilities updated for the company",
"status": 202,
"operation_id": "company:set-company-user-capabilities-54fb80af-576c-4fdc-ba4f-b596c83f15a1"
}Met de teruggegeven operation_id controleer je de status van de bewerking.
Rollen op bedrijfsniveau bepalen tot welke bronnen iemand toegang heeft. Een rolwijziging kan dus toegang tot sites, facturering of bedrijfsinstellingen geven of juist intrekken. In de documentatie over gebruikersrollen en rechten zie je welke toegang bij elke rol hoort.
Toegangsrechten voor gebruikers op afzonderlijke sites bijwerken
Toegang op siteniveau beheer je met het nieuwe endpoint Edit users capabilities for the site.
Anders dan rechten op bedrijfsniveau gelden sitebevoegdheden voor specifieke WordPress sites. Wel zo handig als je een ontwikkelaar of klant toegang wilt geven tot één site, zonder toegang tot het hele bedrijf.
Het endpoint accepteert een user_ids-array en een site_capabilities-array. Zo geef je meerdere gebruikers en sitetoewijzingen op in één request.
Per sitetoewijzing zijn er twee rollen:
site-admin, waarmee een gebruiker beheerderstoegang krijgt tot de toegewezen site en de bijbehorende omgevingen, binnen de beperkingen van de rol.site-developer, voor toegang tot de testomgevingen van de site, met beperkte rechten.
Deze request geeft een gebruiker bijvoorbeeld de rol Site Developer:
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"
}
]
}'Het antwoord bevat een bewerkings-ID waarmee je de update kunt volgen:
{
"message": "Users capabilities updated for the site",
"status": 202,
"operation_id": "company:set-site-user-capabilities-54fb80af-576c-4fdc-ba4f-b596c83f15a1"
}Beheer je als team meerdere klantwebsites? Dan wijs je met dit endpoint siterechten toe vanuit een onboardingscript of een intern beheersysteem.
Problemen met API-bewerkingen oplossen met een nieuwe supportreferentie-ID
We hebben ook een optioneel veld support_reference_id toegevoegd aan de antwoorden van API-endpoints die acties in MyKinsta starten.
Voorheen gaven deze requests een operation_id terug, waarmee je de voortgang van de bewerking kon controleren. Omdat bewerkings-ID’s tijdelijk in de cache staan, kan het lastig zijn om de onderliggende actie te achterhalen als je een mislukte request onderzoekt.
De nieuwe support_reference_id verwijst naar de oorspronkelijke actie. Zo kan Kinsta Support directer onderzoeken wat er is gebeurd.
Het veld kan verschijnen in het eerste API-antwoord, en wanneer je de bewerking controleert via het bestaande endpoint Get operation status:
curl --request GET \
--url https://api.kinsta.com/v2/operations/{operation_id} \
--header 'Authorization: Bearer <YOUR_TOKEN_HERE>'Een bewerking die nog loopt, kan bijvoorbeeld dit teruggeven:
{
"status": 202,
"message": "Operation in progress",
"support_reference_id": 12345,
"data": null
}Mislukt een API-actie? Geef de supportreferentie-ID dan door aan ons supportteam, zodat ze de bijbehorende actie kunnen vinden en onderzoeken.
Omdat het veld optioneel is, moeten integraties operation_id blijven gebruiken om de voortgang te volgen, en support_reference_id bewaren als die beschikbaar is.
Gebruikerstoegang beheren via je eigen tools
Met deze toevoegingen bouw je met de Kinsta API completere workflows voor gebruikerstoegang. Je kunt iemands huidige rechten opvragen, de bedrijfsrol wijzigen of toegang op siteniveau toewijzen, zonder elke wijziging apart in het dashboard te hoeven verwerken.
Ook de nieuwe supportreferentie-ID is handig voor teams: een ID om te bewaren als je API-bewerkingen logt en mislukte requests onderzoekt.
Bekijk de beschikbare endpoints en requestformaten in de Kinsta API Docs.