Two record labels that I built websites for, Kilogbede Records and Same House Records, sell tickets to their shows on their own sites. The tickets are eventOS tickets. The labels' sites reach eventOS through its headless API.
The request sounds small: show our events on our site and let people buy there. The design question underneath is where the rules live once a second website is involved.
Two tempting designs, both wrong
The first is to copy. The partner site keeps its own list of events, prices and remaining tickets, and syncs with the platform now and then. It is quick to build and it is wrong the first time a price changes or a tier sells out between syncs. Now two systems disagree about what is for sale, and a buyer is standing in the gap.
The second is to trust. Give the partner site a powerful key and let it do whatever the organiser dashboard can do. That works until the partner site has a bug, or is compromised, and then the platform's rules are only as strong as the weakest site connected to it.
What a partner site is allowed to do
I settled on a narrower answer. A partner site can read the events and ticket tiers it is entitled to show, start a checkout for a buyer, and be told what happened afterwards.
It cannot set a price. It cannot decide how many tickets are left. It cannot declare that a payment succeeded. Those answers come from eventOS every time, so there is one place where each of them is true.
For the labels, that means dates and ticket tiers are managed in eventOS and nowhere else. Their sites display what the platform says.
Payment happens on the platform's side
When a buyer on a partner site chooses a ticket, the checkout itself is hosted by eventOS. The partner site sends the buyer there and receives them back.
This keeps the partner site out of the payment entirely. It never holds the state of a transaction, so it can never be wrong about one. The page the buyer returns to is feedback for a human. The fact that a ticket exists comes from the platform, after the payment provider has confirmed the payment to the platform directly.
Permission and plan are two separate checks
A partner integration has a key, and the key carries a scope: which organiser's events it can see and which operations it may call.
Separately, the organiser is on a plan, and the plan determines which capabilities are included.
It would be simpler to merge those into one check. I kept them apart because they answer different questions and change for different reasons. One is technical: is this caller allowed to ask? The other is commercial: has this been paid for? A request has to pass both. Merging them would mean that a pricing change could accidentally widen technical access, or the reverse.
Telling the partner what happened
After a purchase, the partner site needs to know, so it can show a confirmation or update its own page. eventOS sends it a signed notification.
Signed, because the partner should be able to tell that the message really came from the platform. And the partner should treat the same notification arriving twice as one event, because networks repeat things. The platform follows the same rule for the payment provider's messages, so I am asking partners for nothing I do not already do.
What this bought
The integration is in production on both label sites, with more in progress. A price or a tier is changed once and every site selling that event reflects it. A partner site having a bad day cannot oversell an event or mark an unpaid ticket as paid, because it was never the one deciding.
The details of keys, limits and endpoints stay private because this is a live platform. The principle is the part worth sharing: an integration should be able to ask for things, and should never be the place where the answer is decided.