> For the complete documentation index, see [llms.txt](https://docs.apexsolutions.lol/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.apexsolutions.lol/forter/getting-started.md).

# Getting Started

How Forter protection works, what the solve returns, and what it takes to replay it cleanly.

If you already know Forter’s mechanism, skip to the **API reference**. This page explains what Forter is, how to tell a site uses it, and how the whole flow fits together — you do not need to reverse-engineer anything.

Everything here assumes you already meet the **Core Requirements** — a Chrome TLS client, the right header order, and a sticky proxy.

## Understanding Forter Protection

Forter is an SDK that many e-commerce sites integrate to decide how much to trust each visit. It watches how the browser behaves and sends that information, encrypted, to Forter’s servers. The site’s backend uses it to score the session; when a session looks safe, Forter issues a `forterToken` cookie and the site lets your requests through.

On the page, Forter shows up as two pieces: a small inline snippet in the HTML that carries the merchant’s configuration, and a larger SDK script loaded from Forter’s own servers. The SDK collects signals about the browser and reports them in encrypted payloads to Forter’s CDN.

## Identifying Forter

Before anything else, confirm the site actually uses Forter. Four signs are enough:

1. **An inline script with Forter’s config.** The page HTML has a script tag carrying `ftr__config` or `ftr__startWidget`. Its `id` is the merchant’s Forter site ID:

```
<script type="text/javascript" id="{site_id}">
  ...
  var siteId = '{site_id}';
  window.ftr__config = { m: { csp: false }, s: "{seed}", si: siteId };
  ...
script>
```

2. **The forterToken cookie.** Once a session is established, the browser carries a `forterToken` cookie and sends the same value (plus a `_tt` suffix) as the `f-sdk-c` header.
3. **Requests to Forter’s servers.** Look for traffic to `*.forter.com` — typically `cdn0`, `cdn3`, and `cdn123`.
4. **The SDK host.** The larger SDK is served from a CloudFront host owned by Forter.

The two values you need are the **site ID** and the **seed**. The site ID is the script tag’s `id`; the seed is `window.ftr__config.s`.

Every merchant has its own pair — the `{site_id}`/`{seed}` above are placeholders, not global Forter values. You can also read them from a traffic capture: the site ID is the first segment of Forter’s CDN URLs (`cdn0.forter.com/{site_id}/{user_id}/prop.json`), and the seed sits in the `forterToken` cookie as `{seed}ck`.

## How a session is built

A Forter session is validated through encrypted payloads that Apex builds for you. You do not need to understand their internals — you only submit them. There are two payloads, a couple of lightweight background pings, and a small proof-of-work that proves the client actually ran the SDK’s logic. Apex handles all of it: it returns the payloads, the ping targets, and the token material, ready to replay.

## Solution Flow

Here is the flow from the client’s point of view:

1. **Request the protected page.** Use a Chrome TLS client and the exact browser header order (Core Requirements).
2. **Confirm Forter and extract** the `site_id` and `seed` from the snippet.
3. **Build the session through Apex.** Send the page details, your sticky proxy, and your real Chrome-on-Windows User-Agent. Apex returns the encrypted payloads, the ping targets, and the token material. See the API reference for the exact request.
4. **Submit the first payload and the pings.** Through the same proxy, post the first encrypted payload and send the background pings.
5. **Submit the second payload.** After a short delay, get the second payload from Apex and post it the same way.
6. **Access the protected endpoints.** Attach the `forterToken` cookie and the `f-sdk-c` header on your final requests.

## Important Notes

{% hint style="info" %}
**Session limits.** A session is valid for about **3 minutes** and supports up to **5 flushes**. You can only flush sessions created with your own API key. Run the whole flow through the same sticky proxy and the same TLS client — changing either mid-session is a reliable way to get flagged.
{% endhint %}