{"user_id":{"customer_user_id":"15667737-366d-4994-ac8b-653fe6b2be4a"},"event_name":"af_purchase","event_revenue":49.99,"event_revenue_currency":"USD","af_customer_event_id": "550e8400-e29b-41d4-a716-446655440000","event_value":{"af_content_id":"SKU-001","af_quantity":2,"custom_parameters":{"promo_code":"SUMMER10"}},"event_url":"https://example.com/checkout/success","timestamp":1712000000000,"ip":"35.244.183.10","user_agent":"Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) ...","email_hashed":"a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4e5f6a1b2"}

{"user_id":{"appsflyer_id":"1234567890abcdef","customer_user_id":"15667737-366d-4994-ac8b-653fe6b2be4a"},"event_url":"https://example.com/products/sneakers","timestamp":1712000000000,"ip":"35.244.183.10","user_agent":"Mozilla/5.0 (Windows NT 10.0; Win64; x64) ...","http_referrer":"https://www.google.com/","email_hashed":"a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4e5f6a1b2"}

A visit carries the attribution parameters that every subsequent event relies on, and the system expects a visit before any user event. If you send an event before a visit, the system classifies it as organic.

Because there's no Web SDK to set the afUserId cookie for you, you need to assign and manage it yourself, as an HTTP cookie set in the Set-Cookie response header, not a client-side cookie written in JavaScript.

Here's why that matters: a client-side cookie (set via document.cookie) expires quickly, as fast as 7 days on Safari, or 24 hours on domains under ITP. Once it expires, the identifier resets, and a returning visitor looks new. A cookie your server sets isn't subject to that cap and can persist up to the browser maximum (Chrome allows up to 400 days). It can also be marked HttpOnly, so page scripts and ad blockers can't read or strip it, and it doesn't rely on any script running on the page at all.

To set and read it:

1. On the first request from a visitor with no cookie, generate a stable, unique ID on your server (for example, a UUID).

2. Return it in a first-party cookie:

   Set-Cookie: af_web_id=<generated-id>; Max-Age=34128000; Path=/; Secure; HttpOnly; SameSite=Lax

3. On every later request, read the value from the incoming Cookie header and reuse it. Don't regenerate it.
4. Send that value to AppsFlyer on every call as appsflyer_id part of the request's user_id object.

You can name the cookie whatever you like; AppsFlyer reads the value you send, not the cookie's name. Just make sure you set it from your own first-party domain.

Every call needs a user_id object with at least one of appsflyer_id (the cookie value) or customer_user_id (your internal user ID). Sending both, when you have them, improves identity resolution.

Here's what to keep in mind: visits are mostly anonymous, so always send the cookie value. For on-site events, add the customer_user_id once the user is identified, and keep sending the cookie alongside it. For events that don't originate in the browser, the customer_user_id alone is enough, as long as AppsFlyer already knows that user from an earlier identified session.

The user_id object is required on every request. At least one of the following identifiers must be provided.

Events and visits must be received no later than 00:30 on the next calendar day in the app's timezone. Late events fall back to the server receive time.

All personal data fields must be SHA256-hashed before sending. Normalize text (lowercase, trimmed) before hashing. Each hash must be exactly 64 hexadecimal characters (case-insensitive).

• Pattern for all hashed fields: ^[a-fA-F0-9]{64}$
• Phone numbers using the phone_number_e164_hashed field must conform to E.164 format (for example, +14155552671) before hashing.

• The afUserId parameter is a unique identifier set by the Web SDK when a user first visits your site.
• If you need afUserId, use one of the methods that follow.

Get afUserId from the HTTP cookie header

• The afUserId is sent by the visitor's browser on calls to your site.
• Extract it from the HTTP cookie header if needed.

Viewing afUserId in the visitor's browser

• View the afUserId in the visitor's browser for troubleshooting and debugging.
• For it to be available, the visitor needs to have first visited a page having the Web SDK at least once.
• The cookie containing afUserId is a first-party cookie in relation to your domain.
• The following procedure was prepared using Chrome 81. There may be differences across browsers and operating systems.

To get the afUserId from the visitor's browser:

1. In your browser, go to your website.
2. Right-click, select Inspect. The browser's inspect element window opens.
3. Go to the (A) Application tab.
4. In the side menu, (B) expand Cookies.
5. Select your website. If it does not display, refresh the browser.
6. In the (C) filter field, enter afUserId. The value of afUserID displays.

AppsFlyer doesn't have a pre-built Segment destination for the S2S API yet, so you'll need to set this up as a custom destination in Segment that sends each event to the S2S endpoint. There are two ways to do this, depending on how much control you need over the data format.

Option 1: Webhooks (Actions) destination

This is the recommended starting point. It requires no code, and all setup happens in Segment's user interface.

To set it up:

1. In Segment, add the Webhooks destination from the destination catalog.
2. Connect it to the source that collects the events you want to send.
3. For each event type, create a mapping that defines the AppsFlyer URL, sets the method to POST, adds the required headers, and builds the JSON payload from the event's fields.

Option 2: Destination Function

Use this option only if the Webhooks mapping can't produce the payload format AppsFlyer needs. A Destination Function is a small JavaScript function that runs inside Segment, receives each event, and sends it to the AppsFlyer endpoint using fetch.

Use this option when:

• The payload needs a nested structure, for example, wrapping user_id inside a user object, that the Webhooks mapping user interface can't build.
• The event data needs to be transformed before sending, such as converting a timestamp to a different format.

Whichever setup you use, point it at this endpoint:

POST https://events.appsflyer.com/v2.0/s2s/inapps/app/web/website-{your_domain}

Authorization: Bearer {s2s-token}
Content-Type: application/json

Get your S2S API key from the AppsFlyer token management page (see Authentication). In the path, use the web app ID (for example, website-www.your_domain), not the Web SDK ID UUID on the app settings page.

Build the JSON body for each mapped event with these fields:

{
  "user_id": {
    "customer_user_id": "<your internal user ID>",
    "appsflyer_id": "<afUserId cookie value, when available>"
  },
  "event_name": "signup",
  "event_url": "<page URL where the event happened>",
  "ip": "<end-user IP>",
  "user_agent": "<end-user user agent>",
  "af_customer_event_id": "<Segment messageId>"
}

1. Keep the Web SDK running on the marketing site: it records the visits, and Segment carries the events. As explained in the introduction to this section, a user needs a visit before an event or the event gets attributed as organic. If you want a fully server-side setup instead, with no Web SDK at all, follow Set up a fully server-side integration.
2. Every call also needs the right identifiers: send the same appsflyer_id or customer_user_id combination described in Send the right identifiers on each call.

Once the destination and payload are in place, roll out in three steps:

1. Map one or two events in Segment (the sign-up event is a good first candidate) and send a test event from the mapping tester.
2. Verify they arrive correctly in the raw report and match up with the marketing-site visit.
3. Once confirmed, expand the mapping to the remaining events.

Once the destination and payload are in place, roll out in three steps:

1. Map one or two events in Segment (the sign-up event is a good first candidate) and send a test event from the mapping tester.
2. Verify they arrive correctly in the raw report and match up with the marketing-site visit.
3. Once confirmed, expand the mapping to the remaining events.