Control API - tenant administrasjon

FoxIDs har separate Control API-flater for distribusjonsoperatører som administrerer tenants og for en tenant som administrerer sin egen konto. Bruk operatøroperasjonene for tenant-klargjøring og administrasjon på tvers avtenant. Bruk selvbetjeningsoperasjonene når en integrasjon skal begrenses til sin egen tenant.

Før du kaller disse operasjonene, konfigurer Control API autentisering og tilgangsrettigheter. Swagger forblir den nøyaktige referansen for tenant egenskaper, plan og betalingsalternativer, valideringsregler og svarskjemaer:

API overflater

Implementeringsoperatør

Operatøroperasjoner kalles i master tenant:

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

Operasjon	Endepunkt	Hensikt
Liste	`GET /!tenants`	List ikke-master tenants med valgfrie filtre og paginering.
Bli	`GET /!tenant?name={name}`	Les en tenants administrasjonsressurs.
Skape	`POST /!tenant`	Angi en tenant, innledende administrator og standardressurser.
Oppdater	`PUT /!tenant`	Erstatt de redigerbare operatøradministrerte tenant-egenskapene.
Slett	`DELETE /!tenant?name={name}`	Slett en tenant og alle tenant data permanent.

Disse operasjonene krever master-tenant tilgangsrettigheter. De er ment for klarert distribusjonsadministrasjon og SaaS klargjøringstjenester.

Tenant selvbetjening

En tenant kaller opp sine egne operasjoner gjennom sitt master-miljø:

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

Operasjon	Endepunkt	Hensikt
Bli	`GET /!mytenant`	Les innringerens tenant-konto og tilgjengelige innstillinger.
Oppdater	`PUT /!mytenant`	Oppdater tillatte selvbetjeningsegenskaper.
Slett	`DELETE /!mytenant`	Slett innringerens tenant og alle tenant-data permanent.

Selvbetjening bruker tenant tilgangsrettigheter og kan ikke administrere en annen tenant. Planendringer, betalingsinnstillinger og tilpassede domener er også underlagt distribusjonens konfigurerte retningslinjer.

Endre verten i disse eksemplene for en selvdrevet distribusjon, og send tilgangstokenet i Authorization: Bearer {access_token}-overskriften.

List opp og identifiser tenants

GET /!tenants godtar filterName, filterCustomDomain og paginationToken. Når begge filtrene er oppgitt, returneres en tenant når enten navnet eller det egendefinerte domenet samsvarer. master tenant og intern bruk tenant-postene er ikke inkludert.

Gjenta en paginert forespørsel med de samme filtrene og det returnerte ugjennomsiktige tokenet til ingen token returneres. Ikke tolk eller modifiser tokenet.

Små bokstaver tenant name er den stabile identifikatoren som brukes i FoxIDs og Control API nettadresser. Behandle det som en uforanderlig automatiseringsnøkkel. Et tilpasset domene er en egen ruting- og merkevarebygging og må ikke brukes som Control API-rutenavnet tenant.

Angi en tenant

Opprettelsen av Tenant er en sammensatt klargjøringsoperasjon. En vellykket forespørsel skaper:

tenant-posten;
tenants master-miljø og dets standard påloggingsautentiseringsmetode;
den første administratorbrukeren;
applikasjonen Control API ressurs og kontrollklient;
distribusjonens konfigurerte standardmiljøer.

Den første administratoren kan motta et oppgitt passord eller etablere et passord gjennom den konfigurerte e-postflyten. Beskytt eventuelle oppgitte passord, og logg ikke forespørselsteksten.

Forespørselen kan også velge en plan og initialisere kunde-, krav og tilpassede domeneinnstillinger der distribusjonen tillater dem. Tenant-navnunikt, planregler, tilpasset domenestøtte og nødvendige administratordata valideres før klargjøringen fullføres. Hvis en konto- eller datafeil avbryter klargjøringen, prøver FoxIDs å rydde opp i ressurser opprettet av den forespørselen; likevel bør klienter behandle enhver feil som mislykket og bekrefte tilstanden før de prøver på nytt med samme tenant-navn.

Oppdater innstillingene for tenant

Tenant PUT operasjoner er fullstendige oppdateringer, ikke oppdateringer. Hent den gjeldende ressursen, bevar alle redigerbare egenskaper som skal forbli uendret, bruk den tiltenkte endringen, og send hele forespørselsmodellen for den valgte operatøren eller selvbetjeningsendepunktet.

Operatørressursen inkluderer distribusjonsadministrerte egenskaper som plantildeling, tilpasset domeneverifisering, bruks- og betalingskonfigurasjon, valuta, mva, timepris og kundedata. Selvbetjeningsressursen viser bare innstillinger som tenant har tillatelse til å administrere.

Hvis du endrer et tilpasset domene gjennom selvbetjening, merkes domenet som ubekreftet til den nødvendige bekreftelsen er fullført. Den valgte planen må støtte et tilpasset domene. Bruk operatøren API for å administrere bekreftelsesstatus; ikke la en uklarert tenant-klient hevde at dens eget domene er bekreftet.

Slett en tenant

Tenant sletting er irreversibel og gjennomgripende. Den sletter alle miljøer i tenant og alle applikasjoner, autentiseringsmetoder, brukere, økter, bevilgninger, nøkler og andre FoxIDs-data. Den fjerner også konfigurasjon på tenant-nivå og egendefinert domeneruting. master tenant kan ikke slettes. Logger som allerede er sendt til et eksternt depot forblir underlagt depotets retningslinjer for oppbevaring og sletting.

Før sletting, stopp trafikk, eksporter konfigurasjon eller data som må beholdes, kanseller eller avstem ekstern fakturering der det er aktuelt, og bekreft tenants tekniske navn. Krev eksplisitt bekreftelse i operatørverktøy. Ikke bruk tenant-sletting for å deaktivere tilgang midlertidig; deaktiver eller oppdater relevante brukere, applikasjoner eller autentiseringsmetoder i stedet.

Automatisering og sikkerhetsveiledning

Foretrekk selvbetjente endepunkter når en klient bare trenger å administrere sine egne tenant.
Begrens operatørlegitimasjonen til en liten, pålitelig klargjøringstjeneste.
Hold det tekniske navnet tenant stabilt og lagre det uavhengig av visnings-, kunde- og egendefinerte domenedata.
Bruk get-modify-put slik at nye egenskaper ikke tilbakestilles av en eldre integrasjon.
Bruk paginering for tenant beholdninger og avstem etter teknisk navn.
Behandle tenant-oppretting og sletting som langvarige sammensatte administrasjonshandlinger; bruk passende tidsavbrudd for klienten og verifiser den endelige tilstanden etter et avbrutt svar.
Forvent at opprette, oppdatere og slette forespørsler vises i kontrollrevisjonsloggen. Leseoperasjoner skrives ikke som revisjonshendelser.

Vanlige feilsvar

400 Bad Request når tenant-, administrator-, plan-, betalings-, kunde- eller tilpasset domenedata er ugyldige.
401 Unauthorized når tilgangstokenet mangler eller er ugyldig.
403 Forbidden når den som ringer mangler den nødvendige master- eller tenant-tilgangsrettigheten.
404 Not Found når den valgte tenant ikke eksisterer.
409 Conflict når et tenant-navn eller en annen unik verdi allerede eksisterer.

Bruk svarteksten for valideringsdetaljer og Swagger UI for svarene deklarert av hver operasjon.