Skip to main content
Event forwarding lets the ShortKit SDK send a duplicate stream of feed-interaction events directly from the device to your own HTTPS endpoint, at the same time it reports them to ShortKit. Use it to feed a recommender system, your data warehouse, or your own analytics, without re-deriving anything from the ShortKit dashboard. It is off by default and turns on the moment you provide a destination URL.

How it works

  1. As users interact with the feed, the SDK collects a small, fixed set of high-value events (see What gets forwarded).
  2. Events are batched (up to 100 per request) and flushed about every 30 seconds while the app is foregrounded, then POSTed as JSON to your URL with the headers you configure.
  3. Delivery is at-least-once: a failed POST is retried with backoff, so your endpoint may occasionally receive the same event twice. Every event carries a unique eventId so you can deduplicate.

Enable forwarding

Provide an https URL and, optionally, auth headers at SDK initialization.
The SDK POSTs to the URL exactly as given. It does not append a path, so provide your full endpoint (for example https://collector.yourdomain.com/v1/shortkit-events), not just the host. The URL must be https. An http URL is rejected and forwarding stays off.

Configuration

The forwarded event set is fixed by the SDK (see below) and is not configurable.

What gets forwarded

Three event types are forwarded. High-volume progress pings are intentionally excluded to keep your ingest light.

Batch shape

Each request body:

Event envelope

Every event shares this envelope. data is type-specific.

Build your collector

Your endpoint is a simple JSON receiver. A minimal handler:
collector.py
Store the whole event JSON (for example in a JSONB column) and parse only the fields you use. You then pick up any fields ShortKit adds later with no schema change.

Field reference

The event envelope and the Core fields below are part of our committed contract. We won’t remove them or change their meaning without notice, so you can build your pipeline on them. Fields under Additional metadata are provided as-is and may change or grow over time.

viewEnd

Core metrics Additional metadata — quality-of-experience and device fields

swipe

All swipe fields are part of the committed contract.

playbackFallback

All playbackFallback fields are part of the committed contract.

Aggregating into sessions

You don’t need to invent a sessionization window. The IDs are already on every event:
  • viewSessionId: one single video view.
  • sessionId: one feed session (feed on screen, open to close), grouping the views in a browsing session. An app background then resume starts a new sessionId, so stitch those yourself if you want a longer-lived session concept.

Best practices

  • Deduplicate on eventId. Delivery is at-least-once, so retries can repeat a batch.
  • Match auth headers case-insensitively. Proxies and HTTP/2 may lowercase header names.
  • Treat the token as a coarse gate. It is embedded in your mobile app and therefore extractable, so also rate-limit, validate payload shape, and rotate the token periodically.
  • Respond quickly with a 2xx. Slow responses count as failures and trigger retries.