Create a segment

Request

curl -X POST 'https://app.mailyte.com/api/v1/segments' \
  -H 'Authorization: Bearer mk_live_YOUR_API_KEY'

const response = await fetch('https://app.mailyte.com/api/v1/segments', {
  method: 'POST',
  headers: {
    Authorization: 'Bearer mk_live_YOUR_API_KEY',
  },
});
const { data } = await response.json();

import requests
response = requests.post(
    "https://app.mailyte.com/api/v1/segments",
    headers={"Authorization": "Bearer mk_live_YOUR_API_KEY"},
)
data = response.json()["data"]

<?php

$response = Http::withToken('mk_live_YOUR_API_KEY')
    ->post('https://app.mailyte.com/api/v1/segments');

$data = $response->json('data');

require "net/http"
require "json"
uri = URI("https://app.mailyte.com/api/v1/segments")
request = Net::HTTP::Post.new(uri)
request["Authorization"] = "Bearer mk_live_YOUR_API_KEY"
response = Net::HTTP.start(uri.hostname, uri.port, use_ssl: true) { |http| http.request(request) }

Response

Success.

• dataobject
  • objectstringsegment
  • idstring

    Unique identifier for the segment.

  • namestring
  • descriptionstring

    Optional free text describing what the segment is for. `null` means NONE — none was written — never "we did not include it": it is a column on the row already read and it is present in a list response as well as on a single segment. It has no effect on the rules; `rules` is the definition.

  • matchstringall | any

    How the rules combine: `all` of them must hold, or `any` one.

  • rulesarray<object>

    The segment definition, round-tripped — this is your own input back, not an internal query representation. Anything outside these three keys is stripped before storage. The compiler that turns rules into SQL is not published and is free to change.

    • fieldstring

      A contact column (`email`, `name`, `status`), one of the engagement pseudo-fields (`opened`, `clicked`, `emailed`) read from the delivery-event ledger rather than from contact data, or any key of the contact's `fields` object, declared or not. Note that `status` here is the stored column, not the contact's derived `state`.

    • opstringequals | not_equals | contains | not_contains | is_set | is_not_set | starts_with | ends_with | greater_than | less_than | before | after | within_days | not_within_days

      `within_days` / `not_within_days` pair ONLY with the engagement fields, and those fields pair only with them. `not_within_days` deliberately includes contacts never emailed at all. `greater_than` / `less_than` compare NUMBERS — a contact attribute is stored as text, so without the cast "10" would sort below "9" and a rule for more than 9 orders would exclude everybody with ten. `before` / `after` compare a date attribute as an absolute instant, unlike the rolling `within_days` window. `starts_with` / `ends_with` are not `contains`: an address AT acme.com and one mentioning acme.com anywhere are different audiences. A value these cannot parse — a non-numeric number, an unreadable date — matches NOTHING rather than everything, because a predicate we cannot evaluate must narrow the audience and never widen it.

    • valuestring

      Always present, unlike the stored rule, which omits the key entirely for operators that take no value. `null` for `is_set` / `is_not_set` — null rather than `""`, which would read as "equal to nothing". A day count of 1–365 for the engagement operators.

  • contact_countinteger

    LIVE. A segment is a query, so this is what the rules match now, not what they matched when it was saved. Always an integer.

  • created_atstring
  • updated_atstring

Returned inside the standard envelope.

Errors

Every status, with what causes it and what to do, is on the error reference.