API Access, Scopes & Developer Permissions Policy
How X2 grants modular API access by service, purpose and permission.
1. Principle
X2 provides access to technology by purpose, service and permission rather than by unrestricted access to the X2 platform.
2. Service-Based Access
Supported API domains may include Catalog, Rights & Publishing, Distribution, Analytics, Audience, Social & UGC Monetization, Royalties & Reporting, AI Verification, Professional Verification and other authorized services. Access to one domain does not imply another.
3. Scope-Based Authorization
Credentials may be limited to read, write or sensitive actions such as catalog.read, catalog.write, rights.read, rights.claims.submit, distribution.submit, analytics.read, royalties.read or ai.verify. Final technical scope names are defined in the API specification.
4. User, Workspace and Organization Authorization
Applications may access only resources belonging to the authorized user, organization or other entity for which explicit permission has been granted. Unrestricted cross-customer access is not part of ordinary API authorization.
5. Application Registration
X2 may require developer or company identity, application name, intended purpose, redirect URLs, requested scopes, expected traffic, security information, data-retention practices and contact details before granting access.
6. Approval Levels
X2 may distinguish standard, verified-developer, restricted and enterprise or partner access based on risk, function and contractual requirements.
7. Sensitive Scopes
Rights transfers, ownership changes, beneficiary changes, payout instructions, KYC or identity data, enforcement actions, bulk claiming and other sensitive functions may require manual approval, stronger verification or separate agreements.
8. Financial Permissions
Permission to read royalty reports does not automatically authorize beneficiary changes, bank-account changes or payout initiation.
9. Rights Permissions
Permission to read Rights data does not automatically authorize rights transfers, claims or ownership changes.
10. OAuth Consent
Applications acting for a user should request explicit scopes and present those permissions clearly. Users should be able to revoke future access.
11. No Universal API Key
X2 does not use a universal credential that automatically grants access to every service. Credentials should be associated with an owner, application, scopes, environment, limits and status.
12. Audit Trail
Sensitive API actions may be logged with actor, application, scope, resource, action, time and result.
13. Sandbox and Production
Sandbox and production access are separate. Production access may require additional verification and approval.
14. Internal Service-to-Service Access
The same least-privilege principle applies to internal X2 services. One service should receive only the API permissions necessary for its function rather than unrestricted database access.
15. Provider Adapters
External DSPs, financial providers, rights organizations and other adapters receive only the data access required for the specific integration.
16. Data Export
Authorized users may export eligible catalog, metadata, rights, reports, registrations or other supported information without receiving unrelated customer data, proprietary internal datasets, security information or fraud models.
17. Fees and Suspension
API access may be free, service-based or usage-based. X2 may suspend an abusive credential or application without necessarily suspending the entire customer account.