# Fullstack experiments URL: https://docs.ablyft.com/developers/application-integration/fullstack/ > Run experiments on your server or in your own application by reading a JSON config file that ABlyft publishes. With the browser snippet, ABlyft decides in the visitor's browser which variation to show. **FullStack** is for cases where the decision, or the change itself, must happen elsewhere: on your server, in your backend templates, or in your own app. Typical examples are search ranking, pricing or sorting logic. For this, ABlyft publishes a **config file** with your running experiments, variations and targeting. Your application reads this file, applies your own variation code, and reports conversions back. > **Check availability first:** FullStack is only visible if your plan includes it, and the **General Settings** section on the FullStack settings > page is marked as deprecated in the app. Before you build a new server-side integration, contact ABlyft support to > agree on the integration path (config file, Feature Experimentation API or SDK). ## How it works 1. You enable FullStack for the **project** and for each **experiment** that should use it. 2. You create **variations of type FullStack** and give them **properties** (key-value pairs). 3. When you publish, ABlyft writes the **config file** to a public URL. 4. Your application loads the file, decides which variation a visitor gets, and applies the variation's properties. 5. Your application sends goals back to ABlyft, so results appear as for any other experiment. ## Step 1: Enable FullStack for the project Go to **Settings → FullStack** in your project. The menu entry appears only if your plan includes FullStack. | Setting | Description | | ------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Fullstack enabled** (toggle in **General Settings**) | Enables the FullStack config file and unlocks additional options for experiments and variations. | | **Secret prefix** | A short random prefix (up to 11 characters) that becomes part of the config file URL, to make it hard to guess. Strongly recommended if the file is publicly accessible. Use **Re-generate secure secret** to create a new one. | | **Cache expiration (ttl)** | How long the config file may be cached: no caching, 1 (default), 2 or 5 minutes. Read-only, contact ABlyft support to change it. | > **Regenerating the secret changes the URL:** A new secret prefix changes the config file URL. Update it everywhere you reference the file. The right side of the page shows the **Config File Implementation**: the **Config file URL** (click to copy), the **Project ID**, **File size**, **Project revision** and **Last published**. If you have environments with **Create a sub-snippet** enabled, **Sub Config Files** lists one additional file per environment. Each contains only the experiments of that [environment](https://docs.ablyft.com/developers/installation/environments/). The URL has this form: ```text https://fullstack.ablyft.com/c/{secretPrefix}-{projectId}.json ``` For an environment file, `-{environment API name}` is appended before `.json`. ## Step 2: Enable FullStack for an experiment 1. Open the experiment and its settings (cog icon). 2. In the section **General**, switch on **Enable FullStack for this experiment**. The toggle is only visible if FullStack is enabled for the project. The experiment is added to the config file and the variation type **FullStack** becomes available. ## Step 3: Create FullStack variations 1. In the experiment, create a variation and choose the type **FullStack**. 2. In the section **FullStack**, add **Variation properties**: key-value pairs that your application receives, for example `color = blue` or `price_variant = premium`. 3. Save. The properties are delivered as `data` of the variation in the config file. A FullStack variation can also have JS and CSS code, see [Custom JavaScript](https://docs.ablyft.com/developers/application-integration/custom-javascript/). ## What the config file contains The file is regenerated every time the project is published. It contains all experiments of the project with the status **running** or **preview**, and for each experiment its variations, audiences, environments and pages. ```json { "project_id": 12345678, "project_name": "example.com", "debug_enabled": false, "published_at": "2026-01-15T10:30:00.000000Z", "stale_experiment_ids": [], "experiments": [ { "id": 87654321, "status": "running", "api_name": "pricing-test", "name": "Pricing test", "traffic_allocation": 100, "audiences_match_type": "any", "metadata": [], "variations": [ { "id": 11111111, "api_name": "original", "name": "Original", "baseline": true, "traffic_allocation": 50, "metadata": [], "data": {} }, { "id": 22222222, "api_name": "premium", "name": "Premium price", "baseline": false, "traffic_allocation": 50, "metadata": [], "data": { "price_variant": "premium" } } ], "audiences": [], "environments": [], "pages": [] } ], "exclusion_groups": [], "goals": [ { "id": 33333333, "api_name": "purchase", "type": "revenue" } ] } ``` The values are illustrative; the field names are the ones ABlyft writes. Notes: * `audiences` contain the targeting definition of each audience, `pages` contain `id` and `api_name`. * `goals` lists the goals used by the exported experiments, with `id`, `api_name` and `type`. * `exclusion_groups` are exported with their entries (`experiment_id`, `traffic`). * `stale_experiment_ids` lists archived experiments (archived within the last 6 months, with participants). It supports the cleanup of stored visitor assignments. ## What your application does ABlyft publishes the file, the logic around it lives in your application: 1. **Load** the config file (cache it for the duration of the cache expiration). 2. **Decide** for each visitor whether an experiment applies (pages, audiences, environments, traffic allocation) and **assign a variation** by the variation traffic allocation. Store the assignment per visitor, so that the visitor keeps seeing the same variation. 3. **Apply** the variation, using its `data` properties. 4. **Report goals** back to ABlyft. For the last point and for the decision logic, contact ABlyft support to get the current integration options for your account. The documentation of the *Feature Experimentation API* describes two HTTPS endpoints for this: `https://fe-api.ablyft.com/v1/decide` (which variation does a user get?) and `https://fe-api.ablyft.com/v1/track` (send goals). Calls are authenticated with an API token (`Authorization: Bearer [token]`) and the visitor's current assignment is passed as `user.bucketing`. This API is offered on request, so confirm availability with ABlyft support before you build on it. ## Mixing FullStack and browser experiments (hybrid) You can run browser experiments and server-side experiments for the same visitors. What matters is that the visitor has **one** consistent assignment. In the browser, ABlyft stores it in `ablyft_exps` in the configured storage (see [Storage & privacy](https://docs.ablyft.com/developers/consent-and-security/storage-and-privacy/)). On the API side, the same information is `user.bucketing`. If both match, tracking and the visitor experience stay correct. You can read the assignment in the browser with `ablyft.get('bucketing')`, see the [`get()` reference](https://docs.ablyft.com/developers/reference/javascript-api/get/#bucketing). ## Next steps - [Environments](https://docs.ablyft.com/developers/installation/environments/): Sub config files per environment. - [Tracking & events](https://docs.ablyft.com/developers/tracking-and-events/): Goals and events in the browser. - [REST API](https://docs.ablyft.com/developers/reference/rest-api/): Manage projects and experiments by API.