How many contacts a saved segment reaches today. The counts on GET /v1/segments/{id} are the ones its last membership refresh left behind, dated by counts.refreshed_at, and they can lag or still be zero after a create; this counts the segment's criteria against the latest data now. It only reads, and saves and changes nothing. Each count is a scan of the account's contacts, so it has its own budget on top of the request limit: 20 per minute and 600 per UTC day for each user, charged only when a count runs. A token with no user shares one such budget per account.

Live counts need the account to be on the latest segment engine. An account that is not yet is refused with 403 live_counts_unavailable: the merchant can ask Privy support to migrate the account, and retrying does not help. An account whose live answers Privy is checking is refused with 403 live_counts_suspended: the suspension lifts on its own within a week, or sooner through Privy support, and retrying in the same session does not help. The endpoint needs the account's new segment builder, and answers 403 segment_builder_required without it. When live counts are paused or a count fails for the moment, the answer is 503 counts_unavailable; retry it after its Retry-After. When a count runs out of time or memory, which an account's size can make happen on every call, the answer is 422 counts_too_large; Privy is notified, and a retry does not help. When Privy cannot count the saved criteria, the answer is 500 counts_failed; Privy is notified, and a plain retry rarely helps. A saved condition the live engine cannot count as written, or that reads all-time activity the account does not have, is 422 segment_not_countable: the segment's criteria are not the request's to change, so read its refreshed counts instead. A live count can differ from the refreshed one, and from the members GET /v1/segments/{id}/contacts lists, until the next refresh.

Required scope: segments_read