Handle errors

The SDK throws an error when a call does not succeed after all retries. This example shows how to handle a pay run batch that fails.

TypeScript / Node.jsC# / .NETRuby

import { VerifiablApiError, VerifiablAuthError } from "@verifiabl/issuer";

try {
  await client.registerNonPiiBatch({ records });
} catch (error) {
  if (error instanceof VerifiablApiError && error.status >= 500) {
    // The retries did not succeed.
  } else if (error instanceof VerifiablApiError) {
    // The API rejected the request. Use error.code and error.requestId.
  } else if (error instanceof VerifiablAuthError) {
    // Examine the credentials and the environment.
  } else {
    // Timeout or network failure.
  }
}

Copy

try
{
    await client.RegisterNonPiiBatchAsync(records);
}
catch (VerifiablApiException exception) when (exception.Status >= 500)
{
    // The retries did not succeed.
}
catch (VerifiablApiException exception)
{
    // The API rejected the request. Use exception.Code and exception.RequestId.
}
catch (VerifiablAuthException)
{
    // Examine the credentials and the environment.
}
catch (VerifiablException)
{
    // Timeout or network failure.
}

Copy

begin
  issuer.register_non_pii_batch(records)
rescue Verifiabl::Issuer::ApiError => error
  if error.status >= 500
    # The retries did not succeed.
  else
    # The API rejected the request. Use error.code and error.request_id.
  end
rescue Verifiabl::Issuer::AuthError
  # Examine the credentials and the environment.
rescue Verifiabl::Issuer::TransportError
  # Timeout or network failure.
end

Copy

Errors

Problem	Error
The API returned an error response	VerifiablApiErrorVerifiablApiExceptionVerifiabl::Issuer::ApiError
The IV is in use already	VerifiablIvReuseErrorVerifiablIvReuseExceptionVerifiabl::Issuer::IvReuseError
The SDK could not get an access token	VerifiablAuthErrorVerifiablAuthExceptionVerifiabl::Issuer::AuthError
The call did not complete in the timeout	TimeoutErrorVerifiablTimeoutExceptionVerifiabl::Issuer::TimeoutError
A network failure prevented a response	TypeErrorVerifiablTransportExceptionVerifiabl::Issuer::TransportError
The request is not valid, so the SDK did not send it	ZodErrorArgumentExceptionArgumentError

• API error response. The error has the HTTP status, the error code and the request ID. Use the code in conditions, not the message. A 5xx status after all retries is a temporary problem. A 429 status is a rate limit. Refer to Rate limits. Other 4xx statuses do not change if you send the same request again.
• IV in use. The IV error is a type of API error. Refer to Reused IV.
• Access token. Examine the client ID, the client secret and the environment.
• Timeout and network failure. These are temporary problems. Refer to Retries and timeouts.
• Request not valid. Correct the value that the error names. Then send the request again.

The timeout error is a DOMException with the name TimeoutError. A network failure gives the error from fetch, usually a TypeError. Use error.status, error.code and error.requestId on VerifiablApiError.

All errors from an API call derive from VerifiablException. Use Status, Code and RequestId on VerifiablApiException.

All SDK errors derive from Verifiabl::Issuer::Error. The timeout error is a type of transport error. Use status, code and request_id on ApiError.

If you need help with a request, give the request ID to Verifiabl support. For the error codes of each operation, refer to the Issuer API reference.

Reused IV

The API rejects an IV that you used before with different content.

• A single registration throws VerifiablIvReuseErrorVerifiablIvReuseExceptionVerifiabl::Issuer::IvReuseError.
• In a pay run, the record gets an error result with the code IV_REUSED. To find these results, use isIvReuseResult(result)result.IsIvReusedresult.code == "IV_REUSED".

Prepare the payslip again to get a new IV and ciphertext. Register the new prepared payslip. Then make a new QR code. If you send the same record again with no change, you get the same error.