Segment Contacts by Source Without Misreading Your Numbers

Your Contacts page says 340 contacts: 210 waitlist, 80 form, 50 chat. The obvious reading is that 210 people came in through the waitlist widget and 80 came through a form. That is not what those numbers mean, and the gap matters as soon as you use them to decide where to spend next week.

source on a contact records the highest-intent action that person has taken, not the door they walked in through. A founder who submits your contact form in March and joins the waitlist in April counts once, under waitlist. The contact_form visit is gone from the breakdown.

The Five Values and the Upgrade Rule

A contact's source is one of five strings, and each one is set by whichever tool created the record:

Contacts are deduplicated on (project_id, email), so one email is one row no matter how many times that person interacts. When an existing contact comes back through a different tool, OperatorStack compares priorities and keeps the higher one:

contact_form (1) then waitlist (3)  ->  waitlist
waitlist (3)     then form (2)      ->  waitlist
chat (2)         then form (2)      ->  chat

The third line is the one that surprises people. Equal priorities do not overwrite, so a tie keeps whatever got there first. form and chat are both priority 2, which means a chat capture followed by a form submission stays on chat.

The upgrade exists for a real sequencing problem. One of the built-in widget flows calls sendContactMessage before joinWaitlist, so without the upgrade a waitlist signup would get permanently stamped contact_form purely because that request landed a few hundred milliseconds earlier.

Filter in the Dashboard

Open Contacts in your project, which the sidebar labels Contacts even though the route is /signups. Two controls matter:

The dropdown has no option for unknown. If you imported a list or created contacts through the API without passing a source, those records exist, they count toward your total, and the only way to isolate them in the UI is to page through All sources. Hit the endpoint directly instead.

Filter Through the API

The contacts list lives on the signups router, scoped to a project by its internal id rather than by your public project key:

GET /v1/projects/{project_id}/signups?source=waitlist&page=1&per_page=50

These are private endpoints, so authentication is a JWT in an httpOnly cookie. From the dashboard the call goes through the Nitro proxy at /api/v1/...; from a script you need to send the session cookie.

The response is the standard paginated shape:

{
  "items": [
    {
      "email": "founder@example.com",
      "name": "Sam",
      "source": "form",
      "source_detail": "Pricing Feedback",
      "referral_code": "a7bK2p",
      "referrals_count": 3,
      "invited_at": null,
      "created_at": "2026-09-14T10:22:05Z",
      "last_activity_at": "2026-09-27T16:04:11Z"
    }
  ],
  "total": 80,
  "page": 1,
  "per_page": 50
}

source=unknown works here even though the dropdown does not offer it. So does source=chat, and so does any other string, which brings up the one behaviour worth committing to memory.

Export One Segment

The export endpoint takes the same two filters and streams a CSV:

GET /v1/projects/{project_id}/signups/export?source=form

The columns are fixed:

email,name,source,referral_code,referrals_count,created_at

Two limits to plan around. The export is capped at 10,000 rows, ordered newest first, so a larger segment silently truncates to your most recent 10,000. And source_detail is not in the CSV even though it is in the list response. If you need to know which form each contact came from, page the list endpoint rather than exporting.

source_detail Tells You Which Form, Not Which Channel

source_detail is a nullable 255-character string, and today exactly one thing writes it: a form submission stores the form's name. A contact created by a form called "Pricing Feedback" gets source: "form" and source_detail: "Pricing Feedback".

Waitlist, chat, and contact widget signups leave it null. So you can segment form contacts down to the individual form, but you cannot segment waitlist contacts any further using this field.

When You Actually Want the Channel

If the question is "which channel sends signups that convert", source is the wrong field. Three other mechanisms carry that answer:

• The os_attribution cookie. The embed script reads utm_source, utm_medium, utm_campaign, and rdt_cid off the URL and stores them in a JSON cookie with a 30-day expiry and SameSite=Lax. It is first-touch: once utm_source or rdt_cid is stored, a later visit with different parameters does not overwrite it. The visitor who found you on Reddit and came back through your newsletter stays attributed to Reddit.
• The referrer on page view events. Every event records the referring URL, which covers traffic that arrives with no UTM parameters at all, such as most links posted in Slack or Discord.
• The contact_created event. Every new contact emits one, with source and source_detail in its metadata. That gives you a dated conversion signal you can chart against your traffic, which the contact record alone cannot do because upgrading overwrites the original source.

Together those three answer the channel question. source answers a different and still useful one: of the people who gave you an email, how many were interested enough to ask for early access rather than just send a message.