Control API - tenant administration

FoxIDs har separata Control API-ytor för distributionsoperatörer som administrerar tenants och för en tenant som administrerar sitt eget konto. Använd operatörsfunktionerna för tenant-administration och tvärtenant administration. Använd självbetjäningsoperationerna när en integration bör begränsas till sin egen tenant.

Innan du anropar dessa åtgärder, konfigurera Control API autentisering och åtkomsträttigheter. Swagger förblir den exakta referensen för tenant egenskaper, plan och betalningsalternativ, valideringsregler och svarsscheman:

API ytor

Implementeringsoperatör

Operatörsåtgärder anropas i master tenant:

https://control.foxids.com/api/master/master

Drift	Slutpunkt	Ändamål
Lista	`GET /!tenants`	Lista icke-master tenants med valfria filter och sidnumrering.
Få	`GET /!tenant?name={name}`	Läs en tenants administrationsresurs.
Skapa	`POST /!tenant`	Ange en tenant, initial administratör och standardresurser.
Uppdatera	`PUT /!tenant`	Ersätt de redigerbara operatörshanterade tenant-egenskaperna.
Radera	`DELETE /!tenant?name={name}`	Ta bort en tenant och alla tenant data permanent.

Dessa åtgärder kräver master-tenant åtkomsträttigheter. De är avsedda för betrodd distributionsadministration och SaaS provisioneringstjänster.

Tenant självbetjäning

En tenant anropar sin egen verksamhet genom sin master-miljö:

https://control.foxids.com/api/{tenant_name}/master

Drift	Slutpunkt	Ändamål
Få	`GET /!mytenant`	Läs uppringarens tenant-konto och tillgängliga inställningar.
Uppdatera	`PUT /!mytenant`	Uppdatera tillåtna självbetjäningsegenskaper.
Radera	`DELETE /!mytenant`	Radera permanent uppringarens tenant och alla tenant data.

Självbetjäning använder tenant åtkomsträttigheter och kan inte administrera en annan tenant. Planändringar, betalningsinställningar och anpassade domäner är också föremål för implementeringens konfigurerade policyer.

Ändra värden i de här exemplen för en driftsättning med egen värd och skicka åtkomsttoken i rubriken Authorization: Bearer {access_token}.

Lista och identifiera tenants

GET /!tenants accepterar filterName, filterCustomDomain och paginationToken. När båda filtren tillhandahålls returneras en tenant när antingen dess namn eller anpassade domän matchar. Posterna master tenant och endast intern användning tenant ingår inte.

Upprepa en sidnumrerad begäran med samma filter och den returnerade ogenomskinliga token tills ingen token returneras. Tolka eller modifiera inte token.

Den gemena tenant name är den stabila identifierare som används i FoxIDs och Control API webbadresser. Behandla det som en oföränderlig automatiseringsnyckel. En anpassad domän är en separat rutt- och varumärkesegenskap och får inte användas som namnet på Control API rutt tenant.

Ange en tenant

Skapandet av Tenant är en sammansatt provisioneringsoperation. En framgångsrik begäran skapar:

posten tenant;
miljön för tenants master och dess standardinloggningsautentiseringsmetod;
den första administratörsanvändaren;
applikationen Control API resurs och kontrollklient;
distributionens konfigurerade standardmiljöer.

Den initiala administratören kan få ett tillhandahållet lösenord eller upprätta ett lösenord genom det konfigurerade e-postflödet. Skydda eventuella angivna lösenord och logga inte förfrågan.

Begäran kan också välja en plan och initiera kund-, anspråk och anpassade domäninställningar där implementeringen tillåter dem. Tenant namnunik, planregler, support för anpassad domän och nödvändig administratörsdata valideras innan administrationen slutförs. Om ett konto- eller datafel avbryter administrationen försöker FoxIDs rensa upp resurser som skapats av den begäran; ändå bör klienter behandla alla misslyckanden som misslyckade och verifiera tillstånd innan de försöker igen med samma tenant-namn.

Uppdatera inställningarna för tenant

Tenant PUT operationer är fullständiga uppdateringar, inte patchar. Hämta den aktuella resursen, bevara alla redigerbara egenskaper som ska förbli oförändrade, tillämpa den avsedda ändringen och skicka hela förfrågningsmodellen för den valda operatören eller självbetjäningsslutpunkten.

Operatörsresursen inkluderar implementeringshanterade egenskaper som plantilldelning, anpassad domänverifiering, användnings- och betalningskonfiguration, valuta, moms, timpris och kunddata. Självbetjäningsresursen visar endast inställningar som tenant har tillåtelse att hantera.

Om du ändrar en anpassad domän via självbetjäning markeras domänen som overifierad tills den nödvändiga verifieringen är klar. Den valda planen måste stödja en anpassad domän. Använd operatorn API för att hantera verifieringstillstånd; låt inte en opålitlig tenant-klient hävda att dess egen domän är verifierad.

Ta bort en tenant

Tenant radering är oåterkallelig och överlappande. Den tar bort alla miljöer i tenant och alla omfångade applikationer, autentiseringsmetoder, användare, sessioner, anslag, nycklar och annan FoxIDs-data. Det tar också bort konfiguration på tenant-nivå och anpassad domänrouting. master tenant kan inte raderas. Loggar som redan skickats till ett externt arkiv förblir föremål för det arkivets lagrings- och raderingspolicy.

Innan du raderar, stoppa trafik, exportera konfiguration eller data som måste behållas, avbryt eller stämma av extern fakturering där så är tillämpligt och verifiera tenants tekniska namn. Kräv explicit bekräftelse i operatörens verktyg. Använd inte radering av tenant för att tillfälligt inaktivera åtkomst. inaktivera eller uppdatera relevanta användare, applikationer eller autentiseringsmetoder istället.

Automatisering och säkerhetsvägledning

Föredra självbetjäningsslutpunkter när en klient bara behöver hantera sina egna tenant.
Begränsa operatörens autentiseringsuppgifter till en liten, pålitlig provisioneringstjänst.
Håll det tekniska namnet tenant stabilt och lagra det oberoende av visnings-, kund- och anpassad domändata.
Använd get-modify-put så att nya egenskaper inte återställs av en äldre integration.
Använd sidnumrering för tenant lager och stäm av efter tekniskt namn.
Behandla tenant skapande och radering som långvariga sammansatta administrationsåtgärder; använd lämpliga klienttimeouts och verifiera det slutliga tillståndet efter ett avbrutet svar.
Räkna med att skapa, uppdatera och ta bort förfrågningar visas i kontrollgranskningsloggen. Läsoperationer skrivs inte som revisionshändelser.

Vanliga felsvar

400 Bad Request när tenant-, administratörs-, plan-, betalnings-, kund- eller anpassad domändata är ogiltig.
401 Unauthorized när åtkomsttoken saknas eller är ogiltig.
403 Forbidden när den som ringer saknar den nödvändiga åtkomsträttigheten master eller tenant.
404 Not Found när den valda tenant inte finns.
409 Conflict när ett tenant-namn eller ett annat unikt värde redan finns.

Använd svarstexten för valideringsdetaljer och Swagger UI för svaren som deklareras av varje operation.