First-Party Proxying

How it works

The browser requests scripts and sends profiling data to your first-party hostname. Your CDN, edge service or load balancer forwards those requests to the corresponding Signifyd origin.

flowchart LR
  B[Customer browser] -->|Scripts and profiling data| P[Your first-party hostname]
  P -->|Script requests| S[cdn-scripts.signifyd.com]
  P -->|Profiling data| D[dp.signifyd.com]

  classDef browser fill:#FFFFFF,stroke:#00A3E0,stroke-width:2px,color:#003459
  classDef proxy fill:#FFFFFF,stroke:#EAAA00,stroke-width:2px,color:#003459
  classDef scriptOrigin fill:#00A3E0,stroke:#0070BD,stroke-width:2px,color:#FFFFFF
  classDef profilingOrigin fill:#0070BD,stroke:#003459,stroke-width:2px,color:#FFFFFF

  class B browser
  class P proxy
  class S scriptOrigin
  class D profilingOrigin

  linkStyle 0 stroke:#00A3E0,stroke-width:2px
  linkStyle 1 stroke:#00A3E0,stroke-width:2px
  linkStyle 2 stroke:#0070BD,stroke-width:2px

Use a hostname on the same registrable domain as your storefront. For example, if your storefront is www.example.com, use a hostname such as assets.example.com. Each storefront domain that performs profiling needs its own first-party configuration.

Avoid path or hostname labels that identify the route as advertising, tracking, fingerprinting or fraud tooling because generic blocklists may target those terms.

Configure the proxy

Configure two upstream origins:

• https://cdn-scripts.signifyd.com for profiling scripts.
• https://dp.signifyd.com for profiling data.

Preserve the original path when forwarding these routes:

• Forward GET /api/* and GET /o/* to the same path on cdn-scripts.signifyd.com.
• Forward POST /fp-web to https://dp.signifyd.com/fp-web.

Configure the two path prefixes rather than individual files. The profiling script requests its dependencies as relative paths, so they resolve against your first-party hostname automatically, and new files added under these prefixes keep working without a configuration change.
For reference, these are the requests the prefixes currently carry:

Allow OPTIONS requests where required by your browser and CDN configuration. Script routes may be cached according to the upstream response headers. Do not cache /fp-web.

The exact routing terminology differs among providers. Follow your provider's current documentation while preserving the paths, methods and forwarding behavior described here.

Deploy the script

After configuring the routes, load the script from your first-party hostname and set data-posturl to the first-party /fp-web endpoint:

<script
  defer
  type="text/javascript"
  id="script-tag-api"
  data-order-session-id="YOUR-SESSION-ID-HERE"
  data-posturl="https://assets.example.com/fp-web"
  src="https://assets.example.com/api/script-tag.js"
></script>

The script loads its additional profiling resources from the same first-party hostname. The profiling payload is then posted to the URL provided in data-posturl.

Use neutral routes consistently. Do not append query parameters to the configured data-posturl.

Required forwarding behavior

Preserve the request

Forward the profiling request body and client-originated headers without modification. Configure the upstream Host header separately as described below.

• Preserve Content-Type, including the multipart boundary.
• Preserve the complete binary request body.
• Preserve the session ID header.
• Do not decompress, parse, transform or re-encode the payload.
• Strip any query string before forwarding /fp-web.

Profiling payloads are normally under 25 KB. The maximum accepted payload size is 100 KB.

Preserve client IP context

Signifyd must receive the customer's IP address rather than only your proxy's egress IP. Preserve the existing X-Forwarded-For chain, with the original client IP first, and prevent intermediate proxies from replacing it.

Before production rollout, work with Signifyd to confirm that profiling traffic contains the expected client IP diversity. Repeatedly observing only CDN or proxy addresses indicates that client IP context is being lost.

Preserve the upstream hostname

When connecting to a Signifyd origin over HTTPS, configure the upstream Host header and TLS server name for that Signifyd hostname. For example, requests forwarded to the profiling data origin must use dp.signifyd.com.

Observe request limits

• Send no more than 74 headers.
• Keep each individual header at or below 1,024 bytes.
• Keep the complete payload at or below 100 KB.

An enterprise web application firewall may reject multipart binary requests. Allow the /fp-web route to pass the documented payload and headers without modification.

Content Security Policy

Update your Content Security Policy to allow the first-party hostname:

• Add the script hostname to script-src.
• Add the /fp-web hostname to connect-src.

Depending on your existing policy and whether the proxy uses the same origin as the storefront, 'self' may already cover these requests. Confirm the effective policy in browser developer tools.

Some device profiling components may still load from other Signifyd-managed origins and cannot be covered by these proxy routes. A blocked optional request does not by itself mean that the first-party integration failed. Validate the complete flow below.

Validate the integration

Test the proxy in a non-production environment and then with limited production traffic:

1. Open the browser Network panel before loading the page.
2. Confirm that script-tag.js and subsequent /api/ and /o/ resources load from your first-party hostname.
3. Confirm that the browser sends /fp-web to the URL configured in data-posturl.
4. Confirm that the proxied request receives HTTP 200.
5. Confirm that the request contains the expected session ID, headers and unmodified payload.
6. Repeat the test on landing, product, account, cart and checkout pages.
7. Repeat with representative privacy or content-blocking tools enabled.
8. Ask Signifyd to confirm successful profiling, session matching and client IP diversity before completing the rollout.

After validation, use one deployment approach for production traffic. Do not include both the direct and proxied script tags on the same page.

Troubleshooting

Scripts return 404

Confirm that /api/* and /o/* preserve their paths and route to cdn-scripts.signifyd.com.

/fp-web returns 400

Confirm that the multipart body, Content-Type boundary and client headers are forwarded unchanged and remain within the documented limits.

/fp-web returns 401 or 403

Confirm that the request reaches the correct Signifyd origin. Contact your Signifyd representative if the request is still rejected.

Profiling succeeds but all client IPs match

Your edge is probably replacing the client IP with its own address. Review the complete X-Forwarded-For chain and any header policies applied by intermediate services.

Direct Signifyd requests still appear

Confirm that the script tag is loaded from the first-party hostname and that data-posturl points to the first-party /fp-web endpoint. Some optional profiling components may still use separate Signifyd-managed origins.