Interoperability by Design

What the S4 APIs are for — and what they are not for.

Integration note2 min readEditorial draft

In brief

  • Creative work rarely lives in one place, so platforms need shared interfaces.
  • The APIs expose capabilities that sit beneath SASENI’s governance; they are not a shortcut around it.
  • Good integrations respect what they cannot see.

At the base of the S4 architecture sit the APIs, providing interoperability with connected platforms. They are the narrowest part of the system and, for most partners, the most visible.

Interoperability is a modest word for an ambitious goal. Creative work rarely lives in one place. A creator may publish on several platforms, sell through another, license through a third and be paid through a fourth. If each platform forms its own isolated relationship with a creator’s verified work, the economy fragments into incompatible pieces.

Shared interfaces prevent that. When platforms connect through common APIs, a creator’s verified identity, holdings and settled value can be recognised consistently wherever they participate. The economy becomes one economy rather than many.

Without shared interfaces

Many economies
  • Each platform forms its own isolated relationship
  • A creator’s identity and holdings differ everywhere
  • The economy fragments

With shared interfaces

One economy
  • Identity, holdings and settled value are recognised consistently
  • Rules travel with every call
  • The economy stays whole

The APIs are not a shortcut around the institution. They expose capabilities that sit beneath SASENI’s governance: identity through S.I., holding through the Wallet, records through the Ledger, finality through Settlement. Calls through the APIs carry the same rules as everything else.

Good integrations respect that. They do not cache balances as if they were final, invent states the Ledger does not recognise, or obscure from users which platform is acting on their behalf. Reference documentation, SDKs and versioning policy are published in the Developers collection.

  • Good integrations do not cache balances as if they were final.
  • They do not invent states the Ledger does not recognise.
  • They do not obscure from users which platform is acting on their behalf.