Staying in sync

Last updated 2 September 2026.

You read on render, so what you show is never more than one page view behind. This page is about the edges: being told sooner, the older block that is still on the wire, and what to do when the link ends.

Being told sooner

Register a webhook URL and Trivela POSTs to it when a value this player is shown may have moved:

POST <your webhook URL>
Authorization: Bearer wh_yourservice_…

{ "subject": "u_8f31c2" }

The subject alone — never the field, never a value. On receipt, answer 202 at once, then make your ordinary link/status call and run the same apply code your render path runs. Trivela times out at two seconds and does not retry; a missed ping costs nothing because the change still arrives on the next render.

  • Check the bearer in constant time, and fail closed if your secret is not configured.
  • Answer 202 for everything past the bearer check — linked, not linked, unknown subject. A 404 would let anyone with the secret ask whether an id is one of your users.
  • Never end a link from a ping. Send no values and no subjectLabel from it either; a ping is not the player being present.

Deploy the receiver before asking us to register the URL. The full contract is on the webhook reference page.

The shared block

Beside sync you will see shared: an older block, frozen at three fields (nationality, platform, club), with fill-if-empty semantics — apply synced only where you hold nothing. A new service can build on sync alone and leave it unread; it stays on the wire for the services that predate sync. If you do read it, the states and rules are on the link/status reference page.