You are about to let an agent send mail. Not an email, which costs nothing to get wrong, but a letter: paper, an envelope, postage, a postbox. If the agent loops or retries at the wrong moment, the mistake lands on your invoice. So you go looking for an API that can be tried safely, and you end up at the Stannp Letters API on APIs.io.
The first thing you notice is how small it is. It has four operations. createLetter posts to /letters/create and writes. postLetter posts to /letters/post and also writes. getLetter reads a letter by id. cancelLetter posts to /letters/cancel and is marked destructive, because it stops a letter before it ships. Stannp has seven APIs on the network, and the post singles this one out as the one where a mistake costs postage.
Then you read the part that matters for your agent. Both write operations take a test boolean. In the contract's words, it produces a "sample PDF without dispatch or charges." So you can preview a real mailpiece for free before anything is mailed. createLetter also takes an idempotency_key "for safe request retries," so a retried send does not get paid for twice. The post's view is that, for a physical and billable action, those are the two properties that matter most, and Stannp has already built both.
You check the rest of what is published. There is an OpenAPI, an overlay, three JSON Schemas (recipient, mailpiece, campaign), a vocabulary and a JSON-LD context. The Agent Skill, "send a transactional letter," and the conversational phrasing were generated by API Evangelist, so Stannp gets no credit for them. The overall score is 74.5, exemplar, down from 76.1 at the previous run. Agent Readiness is 38.6, agent-ready. All seven Stannp contracts score as callable, and none is marked as derived.
Here is where the post turns, and it turns on the catalog itself. The Agent Readiness record says dry_run_mode: false. Yet the contract documents test=true, which skips dispatch and charges. For your purposes that is a dry-run mode. The rubric looks for one under a convention Stannp does not use, so it reads as missing. The post says that either the detector should learn the parameter, or the check is measuring a name rather than a capability. Either way, it says the defect is in the rubric, not in Stannp's API. If you had trusted the flag alone, you might have passed over the very safety rail you wanted.
The post then lists two smaller problems, and says both are the catalog's own. The record lists auth_clarity as bearer, but the contract declares HTTP Basic auth with the API key. And every Stannp API page shows api-eu1.stannp.com as its base URL, while the contract lists the US server first and the page's own entry base is api-us1.stannp.com. For a mail API the post calls that a real problem, because the region decides which country's postal network carries the letter. The letter size enum offers only US-LETTER and US-LETTER-XL-WINDOW, which tells you something about where the defaults point.
The post is just as direct about what belongs to Stannp. postLetter takes a test flag but no idempotency_key, so a retried PDF send could post twice. And cancelLetter does not say how long after creation a letter can still be stopped. If your agent will cancel mistakes, that window is exactly what you would want to know.
So what do you take away? First, read the contract, not just the score. A dry-run mode can exist under a name the rubric does not recognise, and here it does. Second, before you wire this up, check the details the record gets wrong: use Basic auth, and confirm the US host rather than trusting the EU one shown on the page. Third, build around the gaps Stannp still owns. Use test=true to preview, use the idempotency_key on createLetter, and be careful with postLetter, where a retry is unprotected. The post's own conclusion is that Stannp has already done the hard part, and the record just has to catch up with it.
Read the original: https://apis.io/2026/10/27/stannp-letters-api-has-a-free-test-mode-the-rubric-cannot-see/