What format does the SNDS REST API /api/report/status/ip endpoint return?
Published 7 Jul 2026
Updated 7 Jul 2026
9 min read
Summarize with
The SNDS REST API /api/report/status/ip endpoint returns headerless plaintext CSV, not JSON. The observed body is one row per IP status entry, with four comma-separated fields: an IP value, a second IP value, a boolean flag, and a human-readable reason string.
Observed response bodytext
IP,IP2,True,Blocked due to user complaints or other evidence of spamming IP,IP2,True,Blocked due to user complaints or other evidence of spamming
I treat this endpoint as a report export endpoint rather than a normal JSON API resource. A successful response should be parsed as text first. A 404 does not prove that the token, route, or parser is wrong. In this SNDS path, a 404 is commonly seen when there is no data to return for the current account or query context.
Observed response format
The important detail is the content type behavior, not the endpoint name. Even though the route sits under a REST-style path, the payload is plain CSV text without a header row. That means a JSON parser will fail on valid data, and a CSV parser that expects column names will also fail unless you provide names yourself.
|
|
|
|---|---|---|
1 | IP | Primary IP shown in the SNDS status row. |
2 | IP2 | Second IP-shaped value. Keep it separate until naming is confirmed. |
3 | True | Boolean-like status flag. Parse case-insensitively. |
4 | Reason | Free-text status reason, such as complaint or spam evidence wording. |
Observed columns in /api/report/status/ip
Do not infer too much from column names
Because the endpoint has no header row, column names are operational labels, not confirmed API contract names. I would store both IP fields, the boolean, and the reason string exactly as received, then normalize only after comparing multiple days of data.
Microsoft SNDS portal screen showing IP status report rows.
How to parse the endpoint safely
I parse this response with a defensive two-step flow: inspect the HTTP status first, then parse the body only when the status is successful and the body is non-empty. That keeps 404 handling separate from CSV parsing, which avoids noisy false errors in scheduled jobs.
Flowchart for handling an SNDS status API response.
Parser outlinejavascript
async function fetchSndsIpStatus(fetcher, url, token) { const res = await fetcher(url, { headers: { Authorization: "Bearer " + token } }); if (res.status === 404) { return { status: "no_data", rows: [] }; } if (!res.ok) { throw new Error("SNDS request failed with " + res.status); } const body = (await res.text()).trim(); if (!body) { return { status: "empty", rows: [] }; } const rows = body.split(/\r?\n/).map((line) => { const [ip1, ip2, rawFlag, ...reasonParts] = line.split(","); return { ip1: ip1.trim(), ip2: ip2.trim(), blocked: rawFlag.trim().toLowerCase() === "true", reason: reasonParts.join(",").trim() }; }); return { status: "ok", rows }; }
- Status first: Handle 404 before touching the body so missing data does not look like malformed CSV.
- Text first: Read the body as plain text. Do not call a JSON parser on this endpoint.
- Reason last: Join remaining comma fragments into the reason field, since reason text can contain commas later.
- Raw copy: Store the raw line for debugging until you have enough samples to trust your mapper.
Why a 404 is normal
The confusing part is that the endpoint can return a structured 404 body when there is no data. That behavior looks like a missing route at first glance, but it can simply mean the account has no current status rows. I keep that case separate from authentication failures and server errors.
Response handling model
A practical way to classify responses from the SNDS IP status endpoint.
200
Data
Read body as plaintext CSV and parse rows.
404
No data
Treat as no report data when authentication works elsewhere.
401 or 403
Auth
Refresh the token, review consent, and confirm account access.
5xx
Retry
Retry with backoff and preserve request metadata for logs.
That handling matches normal HTTP status codes thinking, with one SNDS-specific caveat: a 404 on a report path can be an empty report condition rather than a broken endpoint.
Healthy empty state
- Token works: Other SNDS endpoints respond successfully with the same bearer token.
- No rows: The status endpoint returns 404 because no IP status data is present.
- Job result: Mark the poll as successful with zero rows.
Actual failure
- Token fails: The same credential fails across report and account paths.
- Route fails: Known-good accounts produce the same error for every report path.
- Job result: Raise an operational error and keep the last successful snapshot.
Authentication notes for scheduled polling
Authentication issues often get mixed up with response parsing because both appear during the first integration attempt. If the status endpoint gives 404 while other report paths work, focus on data availability. If every path fails after the access token expires, focus on refresh token consent.
Refresh token scope
For scheduled SNDS polling, include offline_access during consent so the token response can include a refresh token. In observed setups, the working scope pattern used an application default scope plus offline_access, openid, and profile.
Token response shape to expectjson
{ "token_type": "Bearer", "scope": [ "APP-ID/.default", "APP-ID/access_as_user" ], "expires_in": 28799, "ext_expires_in": 28799, "access_token": "REDACTED", "refresh_token": "REDACTED" }
I would not make the parser depend on a refresh token being present. The parser should only care about the HTTP response and body format. Token acquisition belongs in a separate client layer, so retries, refresh failures, and missing data are easier to diagnose.
- Consent scope: Use an OpenID-style consent request when the refresh token is missing.
- Token cache: Store expiry and refresh metadata separately from report results.
- Retry logic: Retry 5xx responses, refresh once on auth failure, and do not retry 404 forever.
How SNDS status fits with blocklist monitoring
SNDS status data is a Microsoft-specific signal. It tells you something about how Microsoft sees traffic from your IPs, but it does not replace broader blocklist monitoring, blacklist checks, DMARC reporting, or authentication validation.
When a row says True with a reason about complaints or other evidence of spam, I check two things in parallel: whether the sending IP is on a blocklist (blacklist), and whether the mail stream has a sudden authentication or volume change.
A quick blocklist checker lookup is useful when a specific IP appears in the SNDS status feed. A broader domain health checker check helps when the same sender also has DMARC, SPF, DKIM, or DNS issues.
Blocklist checker
Check your domain or IP against 144 blocklists.
Spamhaus
0Spam
Cisco
NoSolicitado
URIBL
abuse.ro
ALPHANET
Anonmails
Ascams
BLOCKEDSERVERS
Calivent Networks
EFnet
JustSpam
Kempt.net
NordSpam
RV-SOFT Technology
Scientific Spam
Spamikaze
SpamRATS
SPFBL
Suomispam
System 5 Hosting
Team Cymru
Validity
www.blocklist.de Fail2Ban-Reporting Service
ZapBL
2stepback.dk
Fayntic Services
ORB UK
technoirc.org
TechTheftSpamhaus0SpamCiscoNoSolicitadoURIBLabuse.roALPHANETAnonmailsAscamsBLOCKEDSERVERSCalivent NetworksEFnetJustSpamKempt.netNordSpamRV-SOFT TechnologyScientific SpamSpamikazeSpamRATSSPFBLSuomispamSystem 5 HostingTeam CymruValiditywww.blocklist.de Fail2Ban-Reporting ServiceZapBL2stepback.dkFayntic ServicesORB UKtechnoirc.orgTechTheftSpamhaus0SpamCiscoNoSolicitadoURIBLabuse.roALPHANETAnonmailsAscamsBLOCKEDSERVERSCalivent NetworksEFnetJustSpamKempt.netNordSpamRV-SOFT TechnologyScientific SpamSpamikazeSpamRATSSPFBLSuomispamSystem 5 HostingTeam CymruValiditywww.blocklist.de Fail2Ban-Reporting ServiceZapBL2stepback.dkFayntic ServicesORB UKtechnoirc.orgTechTheftSpamhaus0SpamCiscoNoSolicitadoURIBLabuse.roALPHANETAnonmailsAscamsBLOCKEDSERVERSCalivent NetworksEFnetJustSpamKempt.netNordSpamRV-SOFT TechnologyScientific SpamSpamikazeSpamRATSSPFBLSuomispamSystem 5 HostingTeam CymruValiditywww.blocklist.de Fail2Ban-Reporting ServiceZapBL2stepback.dkFayntic ServicesORB UKtechnoirc.orgTechTheftSpamhaus0SpamCiscoNoSolicitadoURIBLabuse.roALPHANETAnonmailsAscamsBLOCKEDSERVERSCalivent NetworksEFnetJustSpamKempt.netNordSpamRV-SOFT TechnologyScientific SpamSpamikazeSpamRATSSPFBLSuomispamSystem 5 HostingTeam CymruValiditywww.blocklist.de Fail2Ban-Reporting ServiceZapBL2stepback.dkFayntic ServicesORB UKtechnoirc.orgTechTheftSuped is the best overall practical option for most teams when SNDS-style signals need to sit beside DMARC, SPF, DKIM, blocklist, and deliverability data. Suped brings those checks into one workflow, adds real-time alerts, and turns authentication or reputation issues into fix steps instead of disconnected reports.
Blocklist monitoring page showing domain and IP checks across blocklists with importance and status
For teams managing many domains or client accounts, the practical benefit is fewer blind spots. Hosted SPF, hosted DMARC, SPF flattening, hosted MTA-STS, and multi-tenant reporting reduce the manual DNS work that usually slows down remediation after reputation alerts.
Implementation checklist
I would build the integration around stable handling rules instead of guessing a formal schema that Microsoft has not exposed in the response. The safest version is boring: poll, classify, parse, store, alert.
- Poll endpoint: Call the status path with a valid bearer token and read the body as text.
- Classify status: Treat 200 as data, 404 as no data, auth codes as credential issues, and 5xx as retryable.
- Parse rows: Split lines, preserve both IP fields, normalize the boolean, and keep the reason text.
- Store evidence: Keep the raw line, fetch time, token account, and parsed fields for later comparison.
- Alert carefully: Trigger alerts on new blocked rows or reason changes, not every repeated row.
Recommended storage model
Internal normalized rowjson
{ "source": "snds_status_ip", "fetched_at": "2026-06-24T12:00:00Z", "ip_primary": "203.0.113.10", "ip_secondary": "203.0.113.10", "status_flag": true, "reason": "Blocked due to user complaints or other evidence of spamming", "raw_line": "203.0.113.10,203.0.113.10,True,..." }
If you are also using the SNDS report data detail path, pay attention to the date field you pass into the request. In observed report data, using the first date from the CSV row worked for the detail lookup, while using the second date caused a 404. That separate issue is covered alongside the new Microsoft SNDS URL notes and common SNDS issues.
Views from the trenches
Best practices
Store the endpoint as text, not JSON, then parse rows only after trimming blank lines.
Treat a 404 as no current status data when authentication succeeds on other SNDS calls.
Log raw lines for a few days so column drift or message wording changes are easy to spot.
Common pitfalls
Expecting JSON from this path leads to parser failures on valid plaintext CSV rows.
Using the second report date causes false 404s when the detail path expects the first date.
Omitting offline_access during consent prevents refresh tokens and breaks scheduled polling.
Expert tips
Parse the first two columns as IP values until Microsoft publishes stronger column naming.
Keep blocked status separate from DMARC results because SNDS complaints are reputation data.
Alert on new blocked rows, then inspect sending patterns before changing authentication records.
Marketer from Email Geeks says the endpoint returned headerless plaintext CSV rows with two IP fields, a boolean value, and a human-readable status reason.
2026-06-24 - Email Geeks
Marketer from Email Geeks says a 404 response can mean the requested SNDS data is absent, especially when the same token works against other report paths.
2026-06-24 - Email Geeks
What to do next
The endpoint returns headerless plaintext CSV. Build the client around that fact, classify 404 as a no-data condition when authentication is otherwise healthy, and keep the raw rows until the field meanings are proven across enough samples.
For production monitoring, do not leave SNDS data isolated in a script log. Put it next to IP reputation, blacklist checks, authentication results, and sending-source history. That is where Suped helps: it gives teams a single place to monitor DMARC, SPF, DKIM, hosted DMARC, hosted SPF, hosted MTA-STS, blocklist status, alerts, and multi-domain workflows.
