Skip to main content
CreatorDB communicates request status through HTTP response codes. A response in the 2xx range means the request was successful, while a 4xx response suggests an error caused by invalid credentials, insufficient API credits, or missing parameters. A response in the 5xx range indicates an error on the server side, which may be temporary. If you encounter a 5xx error, please try your request again later. If the issue persists, contact CreatorDB support (support@creatordb.app) for assistance.

Error types and HTTP status codes

The following table shows the different errors types based on the status code of the HTTP response:

Fractional call errors

Requests with a fields parameter have specific failure modes. Unless specified otherwise, all return 400 VALIDATION_ERROR, with details in details[].

Fractional calls not enabled on the key

The fields parameter requires fractional calls to be enabled on your API key. If it is not enabled, any request including fields returns 403 FORBIDDEN with errorCode: "FRACTIONAL_CALLS_NOT_ENABLED". Requests without fields are unaffected and return full responses at the full-bundle price. Contact your account manager to enable fractional calls.

Incorrect fields shape for the endpoint

The fields parameter requires a different data structure depending on the endpoint. Passing an invalid structure returns a 400 VALIDATION_ERROR. This is the most common fractional call error. Per-item endpoints do not accept the legacy :N string-array form. For example, passing ["recentVideos:5"] or ["sponsorList:5"] returns a 400 error. Use { "recentVideos": 5 } instead. For performance-history endpoints, pricing is determined solely by the requested pastDayRange. Sending fields in any shape returns a 400 error.

Unknown or unselectable field names

  • Unlisted fields: Requesting a field name not on the endpoint’s allowlist returns a 400 VALIDATION_ERROR.
  • Undeployed fields: Fields that are not yet deployed return a 400, even when they appear in reference documentation.
  • Sub-fields: Sub-fields are not individually selectable. For example, requesting sponsorList[].brandName or sponsoredVideosPerformance.likes.avg returns a 400. The smallest unit you can select is a whole field or array on the allowlist. To get a sub-field, request its parent block.
Duplicate field names do not trigger an error. They are silently deduplicated, then returned and billed as a single field.

Platform-prefixed enrichment keys on search endpoints

For /{platform}/search, fields keys must use bare endpoint names. Do not prefix the key with a platform name, as the platform is already implied by the URL.

Invalid item counts on per-item endpoints

The value mapped to an array name must be a non-negative integer. Passing a negative number (-5), a non-integer (1.5), or a non-numeric value returns a 400 VALIDATION_ERROR. Passing 0 and null is valid. These return zero items for that array and cost 0 credits. Requesting large item counts is also safe: costs are calculated based only on the items actually returned and are capped at the endpoint’s full-bundle price. You will not be overcharged if you request more items than exist.

Empty fields is not an error

Sending fields: [] on a field-list endpoint or fields: {} on a per-item endpoint returns the full response at the full-bundle price, exactly as if fields were omitted. Neither shape triggers a validation error, and neither returns an empty response.

Insufficient credits

If the estimated cost exceeds your remaining credits, the call returns 402 with errorCode: "INSUFFICIENT_CREDITS" and no partial data. The details object reports what the call required against what is available. A per-key spend limit produces the same 402 status with errorCode: "KEY_SPEND_THRESHOLD_EXCEEDED". Branch on errorCode, not on the status alone.

Response envelope

Every CreatorDB API response follows the same JSON envelope, with a single exception described below. The fields vary slightly depending on whether the call succeeded or failed.

Success

Error

Field reference

Schema notes

UNAUTHORIZED covers two cases. Both cases share the same errorCode. Use message to distinguish them:
  • "API Key is required": The api-key header is missing or empty.
  • "Invalid API Key": The api-key header is present but the key is not recognized.
Malformed IDs and unknown IDs return different status codes.
  • Malformed format (400): If a channelId, videoId, or uniqueId fails format validation (invalid characters or length), it returns a 400 VALIDATION_ERROR with a details[] array describing the problem.
  • Missing resource (404): If the ID is formatted correctly but does not exist in the database, it returns a 404 with a resource-specific errorCode (NOT_FOUND for creator and brand lookups, SUBTITLE_VIDEO_NOT_FOUND for subtitle lookups).
If you are used to APIs that return 404 for all unknown input, expect malformed values to take the 400 path here. Sponsor brandId is validated on characters only. Unlike the creator IDs above, brandId is checked for illegal characters (anything outside letters, digits, ., _, and -) and nothing else. There is no length limit and no domain-shape check, so a value like notadomain or a 300-character string passes validation, reaches the database, and returns 404 NOT_FOUND rather than a 400. Reserve your 400-handling solely for illegal characters here. One parameter can produce several details[] entries. On a 400, details is one-to-many per field, not one message per field. An invalid videoId length trips both the length check and the format check, returning two entries for the same field. An empty sponsor brandId returns both a required-value failure and a character failure. Iterate the whole details[] array so your client does not drop the rest. 404 has two distinct response shapes.
  • Resource 404: Follows the standard error envelope (error: "NotFoundError", errorCode, traceId, timestamp).
  • Path 404: A request to a non-existent URL (e.g. /youtube/no-such-endpoint). It bypasses the standard envelope: error is the plain string "Not Found", errorCode/traceId/timestamp are omitted, and an availableEndpoints array appears in their place.
500 messages are deliberately generic. On the unexpected-error path the underlying message is replaced with "An unexpected error occurred". There is no detail to parse. Use traceId when you contact CreatorDB support.

One endpoint does not return the envelope

POST /youtube/subtitles/download streams the subtitle file as an attachment. It returns no data, creditsUsed, creditsAvailable, traceId, or success. Errors raised before streaming begins do use the standard envelope. That covers pre-flight validation (400) and rate limiting or credit exhaustion (429). An error that occurs mid-stream cannot be reported in the body, so a failed download can leave partial data. Validate the file you received rather than assuming a 200 means a complete track. Every other endpoint in the API returns the standard envelope.

Additional error handling notes

Retry hints are omitted from headers. The API does not send Retry-After, X-RateLimit-Remaining, or similar headers on 429 or 402 responses. Use GET /usage to check your remaining balance, and implement custom backoff logic. error maps to multiple errorCode. The error field contains the runtime class name, and one class can represent multiple error codes. For example, NotFoundError covers NOT_FOUND, SUBTITLE_VIDEO_NOT_FOUND, and SUBTITLE_VSSID_NOT_FOUND. Always branch your code on errorCode. Error responses are free. 4xx and 5xx error responses do not consume credits.
Last modified on September 21, 2026