# Test your integration

This guide takes you from an empty Test environment to a Test click, a Test install, and a signed Test webhook, without touching Production data. For what Test holds and its limits, read [Test mode](https://warplink.app/docs/concepts/test-mode).

## 1. Register a Test app

Turn on Test mode in the organization menu, open **Apps**, and register your debug build. Use the debug build's own bundle ID or package name, since a Test app cannot reuse a Production app's identifiers.

The Test app gets its own host: your live handle with `-test` added, for example `acme-test.aplnk.to`. It also gets its own AASA and assetlinks files, so your Production app never opens a Test link.

## 2. Create a Test key

Open **Keys** in Test and create an SDK key. It starts with `wl_test_`. Production examples elsewhere in these docs use `wl_live_`, so swap the prefix when you copy them.

```bash
# Create an SDK key in Test, using a Test API key
curl -X POST https://api.warplink.app/v1/keys \
  -H "Authorization: Bearer wl_test_YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"name": "Debug build", "type": "sdk"}'
```

## 3. Create a Test link

A Test link always opens a Test app, so pass the Test app's id.

```bash
curl -X POST https://api.warplink.app/v1/links \
  -H "Authorization: Bearer wl_test_YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "app_id": "YOUR_TEST_APP_ID",
    "slug": "summer-sale",
    "destination_url": "https://example.com/summer-sale",
    "ios_url": "myapp://offers/summer",
    "android_url": "myapp://offers/summer"
  }'
```

The link lives on the Test app's host, for example `acme-test.aplnk.to/summer-sale`. It redirects, deep links, sets up deferred deep links, and records clicks the same way a Production link does.

## 4. Use the Test key in your debug build

Configure the SDK with the `wl_test_` key in debug builds and the `wl_live_` key in release builds. The SDK picks its storage from the key prefix, so the two never share attribution state on a device.

## 5. Repeat a first install

Attribution runs once per install. To check it again without deleting the app, call `clearAttribution()` with a Test key. It clears the attribution stored on the device. When automatic deferred checks are enabled, it also starts a new check; otherwise your app runs the check itself. With a `wl_live_` key it does nothing.

```swift
// wl_test_ key: clears stored attribution and starts a new check
let result = WarpLink.clearAttribution()
```

```kotlin
// wl_test_ key: clears stored attribution and starts a new check
val result = WarpLink.clearAttribution()
```

```typescript
// wl_test_ key: clears stored attribution and starts a new check
await WarpLink.clearAttribution();
```

```dart
// wl_test_ key: clears stored attribution and starts a new check
await WarpLink.clearAttribution();
```

If a stored item cannot be deleted, the call reports a storage error and is safe to call again. Each SDK page lists the error it uses, starting from the [SDK overview](https://warplink.app/docs/sdks).

## 6. Check analytics and webhooks

Open **Analytics** in Test to see the Test clicks and installs. They never appear in Production analytics, exports, or Overview.

Add a Test webhook endpoint for the app. It has its own signing secret, separate from your live endpoint. Send a test event and confirm the payload carries `"environment": "test"`. See [Receive referral webhooks](https://warplink.app/docs/guides/webhooks).

An agent can run this whole flow over MCP. After `switch_environment` selects Test, every tool result names the environment it used. See [AI agents](https://warplink.app/docs/ai-agents).

## Limits to plan around

Test holds 100 links and stores 10,000 clicks per billing period, with 90 days of analytics. Past the click limit, Test links keep redirecting and new Test clicks are not stored. Delete Test links you no longer need to make room.