This log starts at public launch. There is no back-history to publish, because there was no public API before it, and inventing entries to make the page look established would be the first dishonest thing on this site.
Every change lands here, including additive ones. A new value inside an existing enum is the change most likely to surprise a client that switched exhaustively, and a changelog that only records removals is no use for catching it.
Entries carry a date and a category: added, changed, fixed, or deprecated. Deprecated entries name the replacement and the date the old shape stops being served.
Reference
| Date | Category | Change |
|---|---|---|
| Launch | Added | POST /verify, POST /batches, GET /batches/{id}, POST /files, GET /credits, GET /account. |
| Launch | Added | Webhooks with HMAC signing, and the sandbox key with reserved addresses. |
| Launch | Added | Idempotency-Key on batch submission, with a 24-hour window. |
Dated entries replace these placeholders on the day the API opens to the public.
What to do with each kind of entry
Each category asks something different of you. An added entry needs no action if your client has default branches. It's still worth a quick search of your code for places that switch on the field it names. A changed entry deserves a careful read, because behavior moved even if the shape didn't.
Fixed entries are the sneaky ones. If you built a workaround for the bug, the fix may now fight with it. Say an entry reports that a count in the batch summary was corrected. Any adjustment you applied on your side should come out on that date.
A deprecated entry carries a retirement date. Put it in your team calendar on the day you read it, with a reminder a month before the old shape stops being served. The overlap is long, and a long overlap is how a deadline gets forgotten.
Keep a short log on your side too
This page can tell you what changed. It can't tell you what your own client assumes, and that second list is the one you'll want during an incident. Keep a few lines in your repository. Note the date you built against these docs, the provisional fields you read, and the places where you switch on result or reason.
There's no feed yet, so checking is a manual job. A recurring reminder once a month is enough for most teams. Reading the page takes five minutes, and with your own list open beside it you can tell at a glance whether an entry touches you.
There's honestly not much more to add here before launch. The entries don't exist yet, and we'd rather leave this page short than fill it with invented history. When the first dated entry lands, the reading habit above is all you need.
Questions developers ask
Where do breaking changes go?
Into a new version, never into /v1/. The entry here says which version carries it and when /v1/ retires.
Is there a feed?
Not yet. When there is one it will be an RSS feed at this URL, and it will be announced here first.
Why does the log start at launch?
Because the API had no public surface before that. A changelog with invented history is worse than a short one.