Skip to main content
A segment is a list of contacts within a project: it’s what you pick as the audience when you send a campaign. There are two kinds, and the difference matters a lot when an external system (your CRM, your backend, your platform) is the one feeding the segment. The static trap is a familiar one: adding always gets implemented, removing almost never does. If your system stops sending the DELETE when someone churns, the segment slowly fills with people who no longer belong — and nobody notices until a campaign goes to the wrong audience. A dynamic segment doesn’t have that problem.

​
Syncing your base with events

This is the recommended approach when the source of truth lives in your platform. The idea: you report facts (events), RQE derives the audience (the segment).

​
1. Send the event from your system

Whenever the fact that defines your audience happens — a successful charge, a renewal, a login — report the event:
You don’t need to create the contact first: if the email doesn’t exist, it’s created for you. For bulk loads use POST /v1/events/bulk (up to 1,000 per call).

​
2. Create the dynamic segment

In the app: Audience → Segments, open the segment and choose Convert to dynamic segment. Then:
  • Rule type: Behavior (event)
  • Action: Triggered the event
  • Event: payment_received
  • In the last: 35 days
That is, literally, “customers who are paying right now”.

​
3. Send

Pick that segment as your campaign audience. There’s no manual sync step and no refresh button.
The rolling window does the dirty work. Someone who churns stops generating the event, falls out of the window, and drops from the segment on their own. Pick a window slightly wider than your billing cycle (35 days for monthly billing) so a charge that runs a few days late doesn’t kick the customer out by accident.

​
Available rules

Each dynamic segment is defined by one rule: The Behavior (event) rule supports the negative operator (Didn't trigger the event), which is handy for win-back: “didn’t trigger payment_received in the last 60 days”.
A segment takes one rule only. To combine criteria (“active customers who also clicked”), build the segment from the most restrictive rule. If you need the exact intersection, resolve it on your side: compute the audience in your system and sync it as a static segment.

​
When membership updates

In other words: to send, you wait for nothing. The hourly cadence only matters if you also hang an automation off entry into the segment.

​
Static segments via API

If you’d rather control membership yourself, the endpoints live in Leads: The :id is the contact’s UUID, not its email. Where to find a segment ID: open it in the app and copy it from the URL, or use GET /v1/leads/:id, which returns the contact’s segment_ids.

​
From an MCP client

If you connect RQE to Claude or Cursor through the MCP server, you can do all of the above conversationally, without writing code:
  • track_event — records the event (also auto-creates the contact)
  • create_segment — creates the segment; accepts the rule to make it dynamic right away
  • list_segments — lists existing ones, with their IDs
  • upsert_contacts — up to 1,000 contacts per call, with their segment_ids

​
FAQ

Can I segment by tags or contact attributes? Not as a segment rule yet. Tags (POST /v1/leads/:email/tags) and attributes are evaluated inside automations, where they’re used to branch a flow. To build audiences, use events. Do contacts created by an event receive emails? Yes, they’re regular project contacts. Keep in mind that creating a contact may enroll it into active automations with new-contact triggers. What if I send the same event many times? Nothing bad: events accumulate as history. The rule looks at the most recent occurrence within the window, so re-sending the event on every charge is exactly the intended usage.