Skip to main content
Customers evaluating Bulkgrid for production will expect clear guidance on how to recover from failure without introducing duplicate work or hidden state problems.

​
Reliability model

Bulkgrid includes asynchronous run handling, explicit status checks, and retry endpoints. Your application should treat Bulkgrid as an external service with network failure, rate limiting, and job-level failure scenarios.
  • keep all Bulkgrid calls on the server side
  • store run IDs durably
  • poll with bounded intervals
  • stop polling on terminal states
  • inspect error fields before retrying

​
Retry guidance

Retry is reasonable for:
  • temporary network issues between your system and Bulkgrid
  • 429 rate limiting after backoff
  • transient provider or crawl failures
Retry is not reasonable when:
  • the request payload is invalid
  • the target URL is permanently unavailable
  • the extraction request is poorly scoped and needs redesign

​
Backoff guidance

A practical default is exponential backoff with jitter for request-level failures, combined with slower polling intervals for long-running jobs.

​
What to log

At minimum log:
  • request endpoint
  • run ID
  • status transitions
  • last error fields
  • retry count
  • final outcome