Server-side tracking is ideal for events you can’t trust from the browser — payments, subscription changes, or any action your backend controls. Because these events originate on your server, they can’t be blocked by ad blockers and are less susceptible to data loss from network issues or tab closures.Documentation Index
Fetch the complete documentation index at: https://docs.saytics.com/llms.txt
Use this file to discover all available pages before exploring further.
When to use server-side vs client-side
Choose the right tracking layer for each type of event.| Use server-side for | Use client-side for |
|---|---|
| Purchases and refunds | UI interactions |
| Subscription changes | Page views |
| Backend-triggered workflows | Button clicks |
| Webhook-driven events | Form submissions |
Node.js SDK
Install the server-side SDK in your Node.js project.saytics.track to record events from your backend.
HTTP API
If you’re working in a language other than Node.js, or you want to send events directly from a webhook handler, use the HTTP API. Send aPOST request to /v1/events with your event payload.
timestamp field is optional. If omitted, Saytics uses the time the request is received. Include it when replaying historical events or processing delayed webhooks.
Batching events
The Node.js SDK automatically queues events and flushes them to Saytics in batches, which reduces network overhead in long-running server processes. In serverless environments (such as AWS Lambda or Vercel Edge Functions), the process may exit before the queue has a chance to flush automatically. Callsaytics.flush() explicitly at the end of your handler to ensure all events are sent.