Politica sull'accesso API, sugli ambiti e sulle autorizzazioni degli sviluppatori
In che modo X2 garantisce l'accesso API modulare in base al servizio, allo scopo e all'autorizzazione.
1. Principio
X2 fornisce l'accesso alla tecnologia in base allo scopo, al servizio e all'autorizzazione anziché tramite l'accesso illimitato alla piattaforma X2.
2. Accesso basato sui servizi
I domini API supportati possono includere Catalogo, Diritti e pubblicazione, Distribuzione, Analisi, Pubblico, Monetizzazione social e UGC, Royalty e Reporting, Verifica AI, Verifica professionale e altri servizi autorizzati. L'accesso ad un dominio non ne implica un altro.
3. Autorizzazione basata sull'ambito
Le credenziali possono essere limitate a lettura, scrittura o azioni sensibili come catalog.read, catalog.write, Rights.read, Rights.claims.submit, distribution.submit, Analytics.read, royalties.read o ai.verify. I nomi finali dell'ambito tecnico sono definiti nella specifica API.
4. Autorizzazione dell'utente, dell'area di lavoro e dell'organizzazione
Le applicazioni possono accedere solo alle risorse appartenenti all'utente, all'organizzazione o ad altra entità autorizzata per la quale è stata concessa l'autorizzazione esplicita. L'accesso illimitato a più clienti non fa parte della normale autorizzazione API.
5. Registrazione della domanda
X2 potrebbe richiedere l'identità dello sviluppatore o dell'azienda, il nome dell'applicazione, lo scopo previsto, gli URL di reindirizzamento, gli ambiti richiesti, il traffico previsto, le informazioni sulla sicurezza, le pratiche di conservazione dei dati e i dettagli di contatto prima di concedere l'accesso.
6. Livelli di approvazione
X2 può distinguere l'accesso standard, sviluppatore verificato, limitato e aziendale o partner in base al rischio, alla funzione e ai requisiti contrattuali.
7. Ambiti sensibili
Trasferimenti di diritti, cambiamenti di proprietà, cambiamenti di beneficiario, istruzioni di pagamento, dati KYC o di identità, azioni esecutive, rivendicazioni collettive e altre funzioni sensibili possono richiedere l'approvazione manuale, una verifica più rigorosa o accordi separati.
8. Autorizzazioni finanziarie
L'autorizzazione a leggere i resoconti sulle royalty non autorizza automaticamente modifiche del beneficiario, modifiche del conto bancario o avvio di pagamenti.
9. Autorizzazioni sui diritti
Il permesso di leggere i dati sui diritti non autorizza automaticamente trasferimenti di diritti, rivendicazioni o cambiamenti di proprietà.
10. Consenso OAuth
Le applicazioni che agiscono per un utente devono richiedere ambiti espliciti e presentare tali autorizzazioni in modo chiaro. Gli utenti dovrebbero essere in grado di revocare l'accesso futuro.
11. Nessuna chiave API universale
X2 non utilizza una credenziale universale che garantisce automaticamente l'accesso a ogni servizio. Le credenziali devono essere associate a proprietario, applicazione, ambiti, ambiente, limiti e stato.
12. Traccia di controllo
Le azioni API sensibili possono essere registrate con attore, applicazione, ambito, risorsa, azione, ora e risultato.
13. Sandbox e produzione
L'accesso alla sandbox e alla produzione sono separati. L'accesso alla produzione potrebbe richiedere ulteriori verifiche e approvazioni.
14. Accesso interno da servizio a servizio
Lo stesso principio del privilegio minimo si applica ai servizi X2 interni. Un servizio dovrebbe ricevere solo le autorizzazioni API necessarie per la sua funzione anziché l'accesso illimitato al database.
15. Adattatori del fornitore
DSP esterni, fornitori finanziari, organizzazioni per i diritti e altri adattatori ricevono solo l'accesso ai dati richiesto per l'integrazione specifica.
16. Esportazione dei dati
Gli utenti autorizzati possono esportare cataloghi, metadati, diritti, report, registrazioni o altre informazioni supportate senza ricevere dati cliente non correlati, set di dati interni proprietari, informazioni sulla sicurezza o modelli di frode.
17. Penali e sospensione
L'accesso API può essere gratuito, basato sul servizio o basato sull'utilizzo. X2 può sospendere una credenziale o un'applicazione abusiva senza necessariamente sospendere l'intero account cliente.