> ## Documentation Index
> Fetch the complete documentation index at: https://docs.wegive.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Joining Events & Reporting

> Join browser sessions, transactions, and recurring plans without counting duplicate revenue.

Use record identifiers to join server notifications and keep session activity, created plans, and collected payments as separate measures.

| Need | Supported field / behavior |
| - | - |
| Browser → server session | Browser `wegive.checkout_session_uuid` / Tealium `wegive_checkout_session_uuid` equals webhook `data.checkout_session.uuid` when session creation has returned. |
| Created → completed | Same `data.checkout_session.uuid`; different delivery UUIDs. |
| Completed → transaction | Session `data.transaction_id` equals donation payload root `id`. Donation body does not contain the session UUID. |
| Completed → plan | Session `data.scheduled_donation_id` equals a persisted recurring-plan root `id`. Action 7 can fire pre-save, so its first delivery may lack that ID. |
| Brand | Session `data.brand.id` / `.name`; resolved processor and URL also provide context. |
| Campaign | `data.campaign.id` is a WeGive ID; `data.utm.utm_campaign` and URL query parameters are separate customer-supplied values. Agree the Salesforce Campaign mapping. |
| App/text/web | Derive using your agreed UTM/query-parameter rules; no automatic channel key exists. |
| Successful collected gift | Use a transaction whose `status` is `2`, or browser `donationSuccess` where observed. Session completion alone does not establish payment success. |
| Confirmation/Salesforce Opportunity lookup | Browser outcome `correlation_id` is separate. The standard donation/session webhook bodies do not carry it or an Opportunity ID; validate any API/CRM join explicitly. |
| Anonymous/known association | Session `donor_id` can be null initially and populated later. No Tealium visitor ID is assigned by these webhooks. |
| Done/abandonment display | Your application owns retention/expiry windows. No automatic expired/abandoned event is emitted. |

For a session-monitoring application, accept a completion even if creation has not arrived yet; a later creation must not move that session back to “online.” Deduplicate retry deliveries, then update business state by session UUID. Keep plan creation and successful payment as separate measures.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.