For the complete documentation index, see llms.txt. This page is also available as Markdown.

Errors and Retries

Understand Pullbay API error codes, HTTP status codes, and how to implement robust retry logic.

Error Response Format

All Pullbay API errors follow a consistent JSON envelope:

{
  "requestId": "3b8dcb68-1f8c-4a7b-b9e7-63a7b9986f24",
  "status": 400,
  "message": "Validation failed",
  "success": false,
  "error": { "code": "VALIDATION_ERROR" }
}
Field
Type
Description

requestId

string

Unique identifier for this request. Save this for debugging and support.

status

integer

HTTP status code mirrored in the body

message

string

Human-readable description of what went wrong

success

boolean

Always false for errors

error.code

string

Machine-readable error code for programmatic handling

The requestId is also returned as the X-Request-Id response header.

Always include requestId when contacting Pullbay support — it allows the support team to instantly locate your request in the logs.


HTTP Status Codes Reference

Status
Name
Retryable?
Meaning
What to Do

200

OK

N/A

Request successful

Process the response data

400

Bad Request

No

Invalid parameters or format

Fix your request and resubmit

401

Unauthorized

No

Invalid or missing API key

Verify your API key

402

Payment Required

No

Insufficient credits

Add credits in your dashboard

403

Forbidden

No

API key lacks permission

Use a key with the right permissions

404

Not Found

No

Endpoint or resource not found

Check the endpoint URL

429

Too Many Requests

Yes

Rate limit exceeded

Back off and wait for reset

500

Internal Server Error

Yes

Temporary server error

Wait and retry with backoff

502

Bad Gateway

Yes

Upstream service unavailable

Wait and retry

503

Service Unavailable

Yes

Maintenance or overload

Wait longer before retrying


Non-Retryable Errors (4xx except 429)

Do not retry requests that return 400, 401, 402, 403, or 404. These indicate problems with your request that won't resolve by waiting:

Retryable Errors (429 and 5xx)

These errors are usually temporary and will likely succeed if retried with backoff:


Common Error Codes

Authentication Errors

Code
HTTP Status
Description
Solution

INVALID_API_KEY

401

API key is malformed or doesn't exist

Check your API key format and value

MISSING_API_KEY

401

Authorization header is missing

Include Authorization: Bearer <key>

Correct format:

Request Parameter Errors

Code
HTTP Status
Description
Solution

VALIDATION_ERROR

400

Parameter has invalid value or wrong type

Check parameter types and constraints

Example:

Fix — include all required parameters with correct types:

Credit Errors

Code
HTTP Status
Description
Solution

INSUFFICIENT_CREDITS

402

Account has run out of API credits

Add credits via dashboard or upgrade plan

Example:

Do not retry a 402 — user action is required (top up credits):

Rate Limit Errors

Code
HTTP Status
Description
Solution

RATE_LIMIT_EXCEEDED

429

Per-second or per-minute rate limit hit

Back off and retry after the reset window

Rate limits are enforced per API key on both a per-second and a per-minute basis based on your plan. The response headers indicate the current limit state:

Handle a 429:

Server Errors

Code
HTTP Status
Description
Solution

—

500

Unexpected server error

Retry with exponential backoff

—

502

Upstream service unavailable

Retry with backoff

—

503

Service maintenance or overload

Wait longer before retrying


Retryable vs. Non-Retryable Summary

Error Type
Status Codes
Retry?

Authentication

401

No — fix your key

Bad request

400

No — fix your parameters

Insufficient credits

402

No — add credits

Forbidden

403

No — check permissions

Not found

404

No — check endpoint URL

Rate limited

429

Yes — wait for reset

Server errors

500, 502, 503

Yes — exponential backoff

Network timeout

—

Yes — retry with backoff


Production-Ready Python Retry Implementation


Debugging Tips

1

Always log the requestId

Every response includes a requestId. Log it alongside every API call so you can reference it when contacting support.

2

Verify your parameters

Common mistakes:

  • Missing required parameters

  • Wrong types (e.g. string instead of integer)

  • Values outside valid ranges (e.g. maxItems exceeding the endpoint limit)

  • Mutually exclusive parameters used together (e.g. page and maxItems)

3

Check your API key

  • Copy-paste directly from your Pullbay dashboard

  • Include the Bearer prefix in the header

  • Check that the key has not been revoked

4

Monitor rate limits

Check rate-limit headers on every response to proactively throttle:

5

Check account credit balance

A 402 means your balance is zero. Add credits in the Pullbay dashboard and do not retry the same request programmatically.

6

For 5xx errors, retry with backoff

500, 502, and 503 are temporary. The recommended strategy is exponential backoff with jitter (see the implementation above).

Frequently Asked Questions

Are credits charged for failed requests?
  • 429 (rate limit) — credits are not charged.

  • 4xx parameter errors — credits are not charged.

  • 5xx transient errors — credits are generally not charged, but check pricing.creditsCharged in the response to confirm.

  • Successful requests (200) — credits are charged as shown in pricing.creditsCharged.

What does VALIDATION_ERROR mean?

It means one or more query parameters failed validation — missing a required field, a value outside the allowed range, or mutually exclusive parameters used together. Check the message field and compare your request against the endpoint's parameter table.

How do I handle rate limits gracefully?

Read the X-RateLimit-Reset header and wait until that Unix timestamp before retrying. The Python example above handles this automatically.

Can I increase retry attempts?

Yes — pass a higher max_retries to the client constructor. However, be aware that aggressive retrying during a sustained outage can look like a DDoS. For sustained failures, implement a circuit breaker that stops retrying after a threshold and alerts your on-call team.

What is X-Request-Id?

It is the same value as requestId in the response body, returned as a response header. Use whichever is more convenient for your logging layer.

Last updated