NewThe global rate limit drops to 1000 requests per minute
BeeL
Get StartedMulti-NIFVeriFactuStripeAPI ReferenceChangelog

Semantic rejections answer 422 and name the rule they broke

A body that parses but breaks a rule now answers 422 with a code and populated details, instead of 400 with an empty details object. 400 is left for what is wrong with the request target.

Changelog

A body that parses but breaks a rule now answers 422 with a code and populated details, instead of 400 with an empty details object. 400 is left for what is wrong with the request target.

What else changed

  • The split, stated once. 400 means the fault is in the request target — an unknown query parameter, a malformed identifier in the path. 422 means the body is syntactically valid but semantically wrong. Several rejections were on the wrong side of that line and have moved.
  • details is no longer empty. A rejection now names the field and the rule: which value was rejected, which field it depends on, which values are allowed. Before, the reason was buried in the message text — readable by a person, useless to code.
  • Where you will notice it. Enabling a default without enabling the feature it depends on, a date range that runs backwards or exceeds the maximum, an identifier that is required and arrived blank. All of these used to be 400 with details: {}.
  • If you branch on the status code, check that you are not treating 422 as a transport error. If you branch on error.code you are already fine: the codes did not change, they were simply not reachable before.

Import managed accounts from a file, and see where each claim stands

Three new operations create managed accounts in bulk from a spreadsheet: download the template, preview what would happen, then apply. The account resource also tells you whether its claim link is still usable.

Unknown query parameters stop being ignored on 2026-09-03

From 2026-09-03 the flat routes reject a query parameter they do not declare with `400`, instead of silently ignoring it. Until then every affected response carries a `BeeL-Warning` header naming the parameter, so you can find them before the date. The rate limits you are actually subject to are now written down.