“Which API should we use?” is often the second question.
The more useful first question is: where does the event become true?
A screen view, button tap or in-app search originates on the client. A completed purchase, refund or account status change may become authoritative on the server. Once that ownership is clear, the transport choice becomes much easier.
Client behaviour and business truth are different.
| Event | Preferred owner | Reason |
|---|---|---|
| Viewed product | App / web SDK | The client directly observes the behaviour |
| Searched destination | App / web SDK | Interaction happens on the client |
| Purchase completed | Backend / REST | The server owns the transaction result |
| Subscription status changed | Backend / warehouse sync | Durable business state should come from the system of record |
Reliability changes the answer too.
If an event must survive a closed browser, intermittent mobile connection or client manipulation, server-side delivery may be safer. If the event is inherently behavioural and useful even before identification, the SDK may be the natural source.
The goal is not ideological purity. It is to avoid having two systems independently claim authority over the same fact.
The practical rule.
Before choosing SDK or REST, write one sentence: “This event becomes true when ___, and ___ is the system that knows that first with enough authority.” Then choose the transport that preserves that ownership.