Server & In-Store Sources

Server pipelines carry events that never touch a browser — POS terminals, kiosks, order-management systems, backend services. This page covers the identity and pipeline settings that make those events join the same graph as your web and app traffic.

Joining server events to the graph

A server event usually has no cookie and no device — its only person-level signal is an identifier your business owns. Bind that field to a custom identity type on the server pipeline’s Identity → Identity Graph card:

properties.loyalty_id  →  loyalty_id

Each event then looks up the person by that value. If your web pipeline binds the same type on the write side (for example from a custom sync that reads the loyalty cookie set at sign-in), in-store purchases and web sessions resolve to one customer.

Use unique anonymousId values per event on shared terminals — a POS till serves many customers, so a shared terminal ID would incorrectly stitch them together:

curl -X POST https://collect.example.com/v1/track \
  -H "Content-Type: application/json" \
  -d '{
    "event": "purchase",
    "anonymousId": "'$(uuidgen)'",
    "properties": {
      "loyalty_id": "LP-99831",
      "value": 42.50,
      "currency": "GBP"
    }
  }'

Web events carry the visitor’s CMP consent state. A POS terminal or kiosk has no CMP — its events carry no consent state at all, so consent-gated identity types would fail closed and never join.

The pipeline-level consent context (on the server pipeline’s Identity settings) fixes this: tick the consent categories that your legal basis covers for this source, and events that arrive with no consent state are treated as granting those categories. Consent-gated types then join those events for the granted categories.

The consent context applies only to events carrying no consent state at all. An event that arrives with explicit consent — granted or denied — is always honoured as-is; the pipeline setting never overrides it.

Vendor IDs on server pipelines

Vendor identifiers (Meta fbp, GA4 client_id, TikTok ttp, …) are only generated on pipelines where that vendor’s Identity Sync is enabled. Server pipelines typically have no syncs, so they mint nothing — instead, when an event resolves to a person, the person’s existing vendor IDs (captured on their web sessions) are attached. That is what you want: the in-store conversion is delivered to Meta with the same browser ID Meta saw on the web, so it matches, rather than with a fresh ID that matches nothing.

See Profile Attachment for how the append works and how to restrict it.

Bot filtering for server sources

Bot filtering scores browser signals — which server events legitimately lack. A curl request or POS integration can therefore score as bot-like and be dropped.

For events sent with the pipeline’s server-side API key and HMAC signature, bot detection is bypassed automatically. For sources that cannot sign requests, attach a bot rule to the server pipeline that allows all traffic: on the pipeline’s Bot Filtering tab, set the rule’s thresholds so server traffic passes (changes save automatically). Keep strict rules on your browser-facing pipelines — the rule is per-pipeline, so relaxing a server pipeline does not weaken web filtering.

Verifying

Use Pipelines → your server pipeline → Live Events: send a test event carrying the join-key value and confirm the resolved event shows the appended profile (user ID, email, vendor IDs) and that destination previews contain the identifiers you expect.

Profile Attachment Overview