Skip to main content
Neural Defend

NeuroVerify Errors and Retries

Do not retry HTTP 400, 401, or 403 without correcting the input, credential, or endpoint access. For direct API calls, retry HTTP 500 and 503 with exponential backoff up to three attempts, and retry HTTP 429 after the Retry-After interval. Official SDKs already implement bounded retries for selected 429, 500, and 503 responses. They do not automatically retry timeouts or network failures because a request may have reached the service and a duplicate can create another billable transaction.

Maintained byNeural Defend
Updated August 7, 2026
Siva Shankar, Co-founder and CTO of Neural Defend.
Siva ShankarCo-founder & CTO
An article-specific diagram for NeuroVerify Errors and Retries organizes key sections including use the documented retry matrix, treat ambiguous failures carefully, use the client error surface.

Use the documented retry matrix

HTTP 400 means the input failed validation. Correct the media or request rather than resending it unchanged. HTTP 401 requires a valid key, while HTTP 403 requires the appropriate endpoint access. None of these conditions improve through immediate automatic retry.

HTTP 429 should honor Retry-After. HTTP 500 and 503 are the server responses designated for bounded backoff. The wire contract describes up to three retries for server failures; the SDK guides define their own attempt counts and caps.

Treat ambiguous failures carefully

A timeout or network interruption does not prove that the service failed to process the upload. The Python and TypeScript SDKs do not automatically retry those failures. Before a manual retry, consider duplicate billing and whether the business workflow can reconcile a late or unknown outcome.

A malformed or unexpected response is a protocol failure. Record the available request identifier, update the client if a compatible release exists, and do not reinterpret missing fields as a normal result.

An article-specific topic map for NeuroVerify Errors and Retries organizes key sections including treat ambiguous failures carefully, use the client error surface, use the documented retry matrix.

Use the client error surface

The official SDKs distinguish local validation, authentication, scope, rate-limit, server, timeout, network, protocol, and unclassified HTTP errors. The TypeScript client also distinguishes caller cancellation. Catch the most specific type before a general HTTP or base error.

A service business rejection with the documented result envelope resolves as a result. Handle it through status and recovery messaging, not through a generic exception path.

Evidence boundary

Limitations

  • This page does not define tenant-specific rate windows, Retry-After values, queueing policy, or a universal retry policy for application-level side effects.

Source record

Sources and references

  1. Neural DefendNeuroVerify OpenAPI retry guidanceVerified August 7, 2026.
  2. Neural DefendNeuralDefend Python SDK retries and exceptionsVerified August 7, 2026.

Use a maintained client

Choose an official SDK

Adopt typed results, local validation, and one documented retry owner for application code.

Review the Python SDK