Server-side events

Some events never happen in a browser: a trial converts, a subscription renews at day 30, a webhook confirms a payment. Your backend knows about them first – often it’s the only thing that knows at all. This section covers sending those events to Fidero from your own servers, and what happens to them on the way through.

Why send events from your server

Partly because you have to: nothing client-side can see a renewal fire in your billing system while the customer’s asleep. There’s no page, no session, no browser moment to instrument.

And partly because it’s dependable. A server-to-server request has no ad-blocker in the way and no page unload to race – for conversions your backend already confirms, like payments and renewals, the server is the reliable place to report from.

What Fidero adds

On its own, a server event knows only what your backend knows: a user ID and an amount. It carries no campaign context and no session – nothing an ad platform could match back to a click.

Fidero holds each person’s context from their earlier browser activity, and delivers the event carrying it: the ad click that brought them in, the campaigns they touched and the profile it all belongs to. How the pieces fit traces exactly that field by field, and the platform overview makes the case for the architecture behind it.

Sending an event

Strip away auth and transport, and a server event is small:

{
  "event": "trial_converted",
  "userId": "user_31e8c2",
  "properties": {
    "transaction_id": "inv_2Kd9X4",
    "value": 19.99,
    "currency": "GBP"
  }
}

POST it to /v1/t, the same endpoint the browser SDK uses. Use a standard name: trial_converted and subscription_renewed only ever fire server-side, and Standard events has the full set. Give conversions a transaction_id – if the browser reports the same conversion, that’s what keeps the count at one. The complete request, from auth to responses, is on the HTTP API.

Before the user has an ID

A server event finds its person through userId, and by the time a renewal or trial conversion fires, there is one. The case to plan for is a conversion that can fire before your backend knows who the visitor is – a checkout webhook landing before the account exists. For that, you thread Fidero’s anonymous ID through your flow, and Connecting anonymous → server shows how.

In this section

HTTP API The endpoint, authentication, the full event envelope and responses.

Sending server events Renewals, webhooks and CRM triggers, worked through end to end.

Connecting anonymous → server Connect conversions that fire before the user has an ID.