code– A stable, unique identifier for the error (e.g.BTF-0010). JD SPB rejections pass through the raw vendor code (e.g.AAC90); transport-level failures use the synthetic markerTRANSPORT. Match on this value rather than on the HTTP status.service– The service or domain that produced the error (e.g.plugin,crm,midaz,fees,jd_spb).category– Machine-readable error category for retry decisions:deterministic,transient,rate_limit, orplugin.message– Detailed guidance to help you resolve the error.requestId– Correlation ID for the request. Present even when empty; include it in support requests.fields– Optional. Structured validation or retry metadata (field-level errors, limit details, and similar).
In the tables below, the title column is a human-readable label for convenience — it is not a field in the response envelope. The envelope returns
code, service, category, message, and requestId. Match on error.code.Bank Transfer errors
The following errors can occur when interacting with the Bank Transfer endpoints. Each error follows our standard structure, making it easier to debug and respond to issues programmatically. Refer to the tables below for a list of possible error codes, what they mean, and how to resolve them.
400
401
403
404
409
410
422
Errors returned by the JD SPB integration are not wrapped in
BTF-* codes. The vendor code is passed through verbatim on the error.code field of the HTTP error envelope (for example, ACE95 for request timeouts, AAC90 for invalid signature rejections, ALN01 for control-number-not-found responses). Refer to the JD SPB vendor documentation for the full list and the corresponding retry policy for each code.429
Rate-limit responses use the
rate_limit category and include a Retry-After header. Back off using HTTP status 429 and that header.
