Politik for API-adgang, omfang og udviklertilladelser
Hvordan X2 giver modulær API-adgang efter service, formål og tilladelse.
1. Princip
X2 giver adgang til teknologi efter formål, service og tilladelse snarere end ved ubegrænset adgang til X2-platformen.
2. Servicebaseret adgang
Understøttede API-domæner kan omfatte katalog, rettigheder og udgivelse, distribution, analyse, målgruppe, social og UGC-indtægtsgenerering, royalties og rapportering, AI-bekræftelse, professionel verifikation og andre autoriserede tjenester. Adgang til ét domæne indebærer ikke et andet.
3. Omfangsbaseret autorisation
Legitimationsoplysninger kan være begrænset til at læse, skrive eller følsomme handlinger såsom catalog.read, catalog.write, rights.read, rights.claims.submit, distribution.submit, analytics.read, royalties.read eller ai.verify. Endelige tekniske omfangsnavne er defineret i API-specifikationen.
4. Bruger-, arbejdsområde- og organisationsautorisation
Applikationer kan kun få adgang til ressourcer, der tilhører den autoriserede bruger, organisation eller anden enhed, som der er givet eksplicit tilladelse til. Ubegrænset adgang på tværs af kunder er ikke en del af almindelig API-autorisation.
5. Ansøgningsregistrering
X2 kan kræve udvikler- eller virksomhedsidentitet, applikationsnavn, tilsigtet formål, omdirigerings-URL'er, anmodede omfang, forventet trafik, sikkerhedsoplysninger, dataopbevaringspraksis og kontaktoplysninger, før der gives adgang.
6. Godkendelsesniveauer
X2 kan skelne mellem standard, verificeret udvikler, begrænset og virksomheds- eller partneradgang baseret på risiko, funktion og kontraktmæssige krav.
7. Følsomme områder
Rettighedsoverdragelser, ejerskabsændringer, modtagerændringer, udbetalingsinstruktioner, KYC- eller identitetsdata, håndhævelseshandlinger, massekrav og andre følsomme funktioner kan kræve manuel godkendelse, stærkere verifikation eller separate aftaler.
8. Økonomiske tilladelser
Tilladelse til at læse royaltyrapporter giver ikke automatisk tilladelse til modtagerændringer, bankkontoændringer eller udbetalingsinitiering.
9. Rettighedstilladelser
Tilladelse til at læse rettighedsdata godkender ikke automatisk rettighedsoverdragelser, krav eller ejerskabsændringer.
10. OAuth-samtykke
Applikationer, der handler for en bruger, bør anmode om eksplicitte omfang og præsentere disse tilladelser tydeligt. Brugere bør kunne tilbagekalde fremtidig adgang.
11. Ingen universel API-nøgle
X2 bruger ikke en universel legitimation, der automatisk giver adgang til alle tjenester. Legitimationsoplysninger bør knyttes til en ejer, applikation, omfang, miljø, grænser og status.
12. Revisionsspor
Følsomme API-handlinger kan logges med aktør, applikation, omfang, ressource, handling, tid og resultat.
13. Sandkasse og Produktion
Sandbox og produktionsadgang er adskilt. Produktionsadgang kan kræve yderligere verifikation og godkendelse.
14. Intern service-til-service-adgang
Det samme princip med mindste privilegier gælder for interne X2-tjenester. Én tjeneste bør kun modtage de API-tilladelser, der er nødvendige for dens funktion, snarere end ubegrænset databaseadgang.
15. Udbyder Adaptere
Eksterne DSP'er, finansielle udbydere, rettighedsorganisationer og andre adaptere modtager kun den dataadgang, der kræves til den specifikke integration.
16. Dataeksport
Autoriserede brugere kan eksportere kvalificerede kataloger, metadata, rettigheder, rapporter, registreringer eller andre understøttede oplysninger uden at modtage ikke-relaterede kundedata, proprietære interne datasæt, sikkerhedsoplysninger eller svindelmodeller.
17. Gebyrer og suspension
API-adgang kan være gratis, servicebaseret eller brugsbaseret. X2 kan suspendere misbrug af legitimationsoplysninger eller applikation uden nødvendigvis at suspendere hele kundekontoen.