Skip to main content
GET
/
api
/
email
/
accounts
/
warmup-analytics
Get Warmup Analytics
curl --request GET \
  --url https://app.puffle.ai/api/email/accounts/warmup-analytics \
  --header 'Authorization: Bearer <token>'
{
  "analytics": {},
  "transitions": {}
}
CLI: 
puffle email account warmup-analytic

​
Overview

Separated from GET /api/email/accounts so the UI can render the account list immediately and lazy-load the slower warmup data without blocking the page. Two things happen in one pass:
  1. Analytics fetch. For every account with warmup_status ∈ {warming, warmed, active} and a set email_address, we pull total_sent, total_received, health_score, warmup_reputation (0–100), and daily_data from the warmup provider. Fetches are serialised to avoid provider rate limits.
  2. Auto-transitions. Two transitions are applied inline and reflected in the transitions map:
    • Ban / suspend: if the provider warmup status is -1 (banned), -2 (spam unknown), or -3 (suspended), we set our warmup_status to banned/suspended and status to error.
    • Graduate: if a warming account has warmup_reputation ≥ 90 AND total_sent ≥ 200, we flip both warmup_status and status to active.

​
AI agent notes

Warmup is a multi-day process. warmup_reputation climbs slowly and the daily counts update incrementally. Expect graduation (warming → active) in roughly 2–3 weeks for a new inbox, not hours. Polling this endpoint more than once every few minutes is wasteful.Reading the response:
  • analytics is keyed by accounts.id — not by email address.
  • Accounts that failed their warmup analytics fetch are silently omitted from analytics. Check the account list for which IDs you expected.
  • transitions is a diff, not a snapshot. It only contains entries for rows that changed status on this call — empty object {} means nothing flipped.
Gate campaigns on status: "active", not warmup_status. An active account is send-eligible; a warming account blocks campaign emails.When an account turns banned: alert the user. There is no retry path — the user must create a new email address on the same domain (or a new domain).Chains with: retryAccountWarmup for stalled pending accounts, launchCampaign once all senders are active.

Authorizations

​
Authorization
string
header
required

Bearer authentication header of the form Bearer <token>, where <token> is your auth token.

Response

Per-account warmup analytics plus any status transitions applied on this call.

​
analytics
object
required

Map of accounts.id → analytics payload. Only accounts with warmup_status ∈ {warming, warmed, active} and a set email_address are included. Accounts that failed to fetch because of a warmup-provider error are silently omitted.

​
transitions
object
required

Map of accounts.id → the status change applied during this call. Present only when a graduation or ban/suspend actually flipped the row — empty object {} if nothing changed. Use this to refresh UI state without re-reading accounts.