Picture this. You run payments for a small company, and your team has just wired up Lob's Checks API to print and mail paper checks to vendors. It works. Then a finance lead walks over and asks a simple question: if someone spots a wrong amount, can we stop the check? You say yes, because there is a cancel operation. You may want to check that first.
The Lob Checks API prints and mails physical checks drawn on a bank account you have verified with Lob. It has four operations: list, create, retrieve and cancel. List is GET /checks, newest first, with filters for date created, metadata, scheduled, send_date, mail_type and status. Create is POST /checks. Retrieve is GET /checks/{chk_id}. Cancel is DELETE /checks/{chk_id}. The contract is OpenAPI version 1.20.2, served from https://api.lob.com/v1 with Basic auth, and it is one of 48 APIs Lob publishes on the network.
Cancel is the one to read closely, because a check is the one Lob mail piece that moves money, and the contract says plainly that you usually cannot take it back. The description reads: "This can only be done if the check has a send_date and the send_date has not yet passed." If the cancel succeeds, you are not charged. The same description ends with "Scheduling and cancellation is a premium feature," available only on a higher Print & Mail Edition.
Put those sentences together and the design is clear. A check created without a future send_date goes into production right away, and the API has no undo. If you want a review step, such as a hold for approval or a same-day correction, you have to schedule every check into the future. That requires the paid tier. So the honest answer to your finance lead is: yes, but only before the send date, and only if you are on the right edition.
There is a helpful filter for this pattern. scheduled=true returns only checks whose send_date is later than date_created, so you can list exactly the checks you can still cancel.
Now look at create. It accepts an Idempotency-Key header or an idempotency_key query parameter, each up to 256 characters. Both are optional. On an endpoint that prints money onto paper, a retry without a key can mail a second check. Lob does not require the key, so you should require it in your own code.
The body has firm limits worth validating before you call. Amount is in US dollars, rounded to two decimals, with a maximum of 999999.99. Mail_type accepts only usps_first_class. Memo can be up to 40 characters. The bottom of the check page is a oneOf: either a message of up to 400 characters or a check_bottom template, but not both. Check_number starts at 10000 for a new bank account unless you set it, then increments from the last number used.
Here is the turn, and it is about the record itself. The post that reports all this also notes what the contract leaves out. All four operations document only a 200 and a default response. No 4xx response is described. That means the contract does not tell you what an expired cancel window, an unverified bank account or a duplicate idempotency key returns. You will find out by calling the API. The catalog's own scores fit that picture: Lob scores 52.9 on the Kin Score, which is developing, and 42.4 on Agent Readiness, which is agent-native. The write-up is candid that the documentation is thinner than the money at stake.
So what do you take away for your finance lead? Schedule every check you might need to stop. List scheduled=true to find the ones you can still cancel. Send an idempotency key with every create. And because no error responses are documented, branch your error handling on the error body, not on documented status codes, until Lob publishes them.
Read the original: https://apis.io/2026/11/12/lob-checks-api-cancels-a-paper-check-only-before-it-mails-and-only-on-a-paid-edition/