Confirm the source for a scanned campaign

Bind a newly scanned OnlyFans tracking link to one of your registered source domains, one at a time or in bulk.

After a scan populates your of_campaigns spine, each OF tracking link the engine found still needs a source before its fans attribute correctly. This is the onboarding loop for that.

Read the queue

curl "https://app.tease.link/api/admin/source-layout" \
  -H "Authorization: Bearer $TEASE_API_KEY"

Every scanned campaign comes back with a fresh proposal for the unassigned ones:

{
  "campaigns": [
    {
      "provider_id": "8740960",
      "name": "insta_promo_1",
      "source_state": "pending",
      "proposed_domain": "ig-main.link",
      "proposed_channel": "instagram",
      "proposal_basis": "source",
      "subscribers": 42,
      "revenue_cents": 18400
    }
  ],
  "domains": ["ig-main.link", "reddit-1.link"],
  "summary": { "total": 90, "known": 12, "pending": 78, "pending_with_traffic": 34 }
}

proposal_basis tells you where the guess came from: assigned (already known), rule (an existing source_link matched), source (a channel keyword in the name, resolved to a domain you've bound that channel to before), source_new (a channel keyword, but no domain bound to it yet), name (the domain's own hostname appears in the link name), or none. Rows are sorted pending-with-traffic first, then by revenue, then by subscribers.

Confirm one campaign

curl -X POST "https://app.tease.link/api/admin/campaigns/8740960/assign-source" \
  -H "Authorization: Bearer $TEASE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"domain_source": "ig-main.link", "channel": "instagram"}'

This writes (or updates) a provider_id-matched source_link rule at a low priority — an explicit owner pick beats broader name_prefix/regex rules — marks the campaign known, and runs a targeted re-attribution scoped to just this link's fans: both a re-match of fans who already have a fan_source row, and an "establish" pass for fans who converted through this campaign's subscriber feed and never got a row at all (the two are different populations — re-resolve alone can't reach the second one).

There is no full re-resolve on this path, on purpose

A full re-resolve of every fan on the account holds the database write lock long enough to return 500s to concurrent writes. Both the single and bulk assign endpoints scope the re-attribution to only the campaign(s) you just touched.

Confirm many at once

Two request shapes, both in one transaction:

# Mode A — many campaigns, one target domain
curl -X POST "https://app.tease.link/api/admin/campaigns/assign-source-bulk" \
  -H "Authorization: Bearer $TEASE_API_KEY" -H "Content-Type: application/json" \
  -d '{"provider_ids": ["8740960", "8740961"], "domain_source": "ig-main.link"}'

# Mode B — each campaign to its own proposed target
curl -X POST "https://app.tease.link/api/admin/campaigns/assign-source-bulk" \
  -H "Authorization: Bearer $TEASE_API_KEY" -H "Content-Type: application/json" \
  -d '{"assignments": [
        {"provider_id": "8740960", "domain_source": "ig-main.link"},
        {"provider_id": "8740962", "domain_source": "reddit-1.link"}
      ]}'

A bad provider_id or an unknown domain is reported per-id in errors; it never fails the whole batch. Re-attribution runs once per affected page, not once per campaign.

Undo a confirmation

curl -X POST "https://app.tease.link/api/admin/campaigns/8740960/unassign-source" \
  -H "Authorization: Bearer $TEASE_API_KEY"

Deactivates the rule (kept for audit, never deleted), returns the campaign to pending, and re-runs the same targeted re-attribution — fans downgrade honestly to "needs a source" instead of silently keeping a source the owner just revoked. of_transactions is untouched; a later re-assign fully re-establishes every fan from of_conversions.

What's next

Create a standing source-link rule — for a pattern that should auto-match future links, not just this one.
Fix a fan's wrong source — for individual fans, not whole campaigns.