RepassError (ou subclasse). Erros da API espelham o envelope de erro { error: { type, code, message, param? } }; falhas de transporte (rede/timeout) viram erros próprios.
Hierarquia
Todas herdam de
RepassError, então catch (err) { if (err instanceof RepassError) … } captura qualquer caso.
Propriedades
Cada erro carrega:number | undefined
HTTP status, quando veio de uma resposta da API.
string | undefined
error.type do envelope (ex.: invalid_request_error).string | undefined
error.code do envelope (ex.: resource_not_found).string | undefined
Campo que originou um erro de validação.
unknown
Detalhes de validação (Zod), em erros 400.
string | null
Id da requisição (header
x-request-id), quando a API o emite, informe ao suporte.unknown
Payload bruto da resposta, para depuração.
Estreitando no catch
Como
404 e 409 compartilham type: "invalid_request_error" no envelope, o SDK distingue pela classe (RepassNotFoundError vs RepassConflictError), prefira instanceof a comparar type.Erros de transporte
Timeouts e falhas de rede não têmstatusCode. O SDK já re-tenta requisições idempotentes; o que escapa do maxRetries é lançado: