Skip to main content
Every Sixtyfour API error returns an HTTP status code and a JSON body. POST /oauth/token is the exception: it uses the OAuth error format. Branch on code, not on the text of detail.

Error body

Examples on this page show only detail.

Error Response Format

detail is a string, a list of field errors, or an object.

String

Most errors carry a string detail:

Field errors

Request validation errors (422) carry a detail array with one entry per invalid field. loc is the path to the field. ctx, when present, holds the rule the value broke, such as {"max_length": 100000} for a research_plan that is too long.

Object

Workflow errors carry an object with a code and a message:
Other objects:

OAuth token errors

POST /oauth/token returns errors in the OAuth format, error and error_description, without detail, code or correlation_id:
A 429 from POST /oauth/token uses the detail format with Retry-After. See Rate Limits.

HTTP Status Codes

Common Error Types

400 Bad Request

Causes:
  • Missing required fields in request body
  • Invalid field types or formats
  • Malformed JSON payload
  • Empty or invalid lead/company data
  • Company Intelligence with "tier": "scout". Scout is a People Intelligence tier
  • A workflow definition that fails validation, such as one with no blocks, incompatible blocks, or broken edges. The response is Workflow validation failed, with one validation_errors entry per problem
  • A workflow definition nested more than 64 levels deep, with detail.code workflow_definition_too_deep
  • Sending webhook_payload to /workflows/run for a workflow whose source block is not webhook
  • Triggering a read_csv workflow without a valid specs_override.resource_handle_id from /storage/csv/upload, or with a handle_id that belongs to a different organization
  • webhook_payload is missing required columns from the webhook block’s input_schema, or is malformed JSON
  • webhook_payload rows with top-level keys that start with _: Invalid input payload: Webhook input contains reserved top-level keys starting with '_' ...
  • Running a webhook workflow without webhook_payload when it has no saved sample input: Webhook input is required but not provided
  • A /storage/csv/upload file with column names that start with _, other than _row_id: Column names must not start with an underscore: ...
  • Invalid search exclusions: sending the deprecated exclude_public_ids in company mode (people-only) or alongside exclude_entity_ids, using a saved exclusion list whose entity type doesn’t match the search mode or that is not yet ready, or sending exclusions on a cursor request — see Search Exclusions
  • A Bulk Intelligence webhook_url that is not https://. Async-job endpoints return 422 for the same URL
  • A webhook_url query parameter on POST /workflows/run. Add an outgoing_webhook block instead
  • An invalid cron expression or timezone on a schedule: Invalid schedule — check the cron expression and timezone.
  • Invalid monitor requests. See Monitors
Examples: Company Intelligence with "tier": "scout":
A workflow with no blocks:
Each save checks the schema and edges, block type compatibility, required block fields, and every column a block references against what its upstream blocks produce. Each entry in validation_errors: How to fix:
  • Fix each field named in detail and resend
  • For workflow runs, match the request body to the source block: webhook_payload for webhook workflows (Incoming Webhooks) or specs_override.resource_handle_id for read_csv workflows (Workflow Execution).

401 Unauthorized

Causes:
  • Missing credentials
  • Invalid, revoked, or expired API key
  • Invalid or expired OAuth bearer token
  • An API key sent as Authorization: Bearer
The detail text varies by endpoint; branch on the status or code. Example:
How to fix:
  • Ensure the x-api-key header is included in every request, with no extra whitespace, or send an OAuth token as Authorization: Bearer. See Authentication
  • Send API keys only in x-api-key; see How the API picks a credential
  • Check that your API key hasn’t been revoked or expired
  • Request a new OAuth token before the old one expires
  • Get a new API key from the dashboard

402 Payment Required

Causes:
  • Your balance doesn’t cover the request’s estimated cost. See Credit Costs
  • Your organization has no active subscription
  • Your team has reached its monthly spend limit, including when you create a monitor or change its tier
Examples:
When automatic top-ups are on and one has been requested, a workflow run or Bulk Intelligence start returns a 402 with Retry-After: 30. Retry after the delay; once the top-up is paid, the start goes through.
If the balance stops covering a run after it is accepted, an async job ends failed with error set to Insufficient API credits, and a sync request returns 500. How to fix:
  • Add credits or upgrade your plan in the billing section before resubmitting
  • Reduce the row count or use a cheaper tier to lower the estimated cost. See Credit Costs
  • For a team spend limit, ask an organization admin to raise it
Nothing is charged when a request returns 402.

403 Forbidden

Causes:
  • Requesting a tier that is not enabled for your organization: high, scout, or xhigh (micro, low, and medium are available to every organization)
  • Requesting a tier your organization has but your team is excluded from. The response is the same 403 an organization without the tier gets
  • Calling /v1/atlas/* when Atlas is not enabled for your organization
  • Calling any /monitors endpoint when Monitors are not enabled for your organization
  • Creating or updating a monitor with the 5m frequency or micro tier when they are not enabled for your organization
  • Your organization’s access to Sixtyfour has been locked
Examples:
How to fix:
  • Contact support@sixtyfour.ai to request access to a restricted tier or feature
  • Use a tier your organization has access to, such as low or medium

404 Not Found

Causes:
  • Workflow ID does not exist or was deleted
  • Run or job ID does not exist, has expired, or is invalid
  • Resource does not belong to your organization
  • The workflow or run belongs to another team. API keys and OAuth clients see only their own team’s workflows and runs
  • Monitor or row ID does not exist, or the monitor belongs to another team
  • A monitor handle_id that does not exist or belongs to another team: Upload handle not found.
  • GET /monitors/for-run/{workflow_run_id}/{block_id} for a step that started no monitor: No monitor was started by that step.
  • GET /v1/atlas/investigations/{investigation_id}/report.pdf before a report was requested, or after the last build failed. Send POST /v1/atlas/investigations/{investigation_id}/report, with retry_failed: true after a failure. It is also 404 once nothing reportable is left in the investigation
Examples:
GET /job-status/{job_id} returns an object:
How to fix:
  • Verify the workflow ID using GET /workflows
  • Verify the job_id from your run response
  • Ensure you’re accessing resources created by your organization, with a key or OAuth client from the team that owns them

409 Conflict (Monitors)

Causes:
  • Requesting GET /monitors/{monitor_id}/runs/{run_id}/changes when the run is running or failed. Changes are available only for completed runs; check the status with List monitor runs.
  • Triggering a monitor that is cancelled or paused
  • Updating a cancelled monitor or switching one of its rows on or off
  • Reusing a monitor idempotency key with different creation settings or file contents
  • Triggering a monitor, or changing its frequency or is_active, while its status is starting or failed, before every row from an uploaded file is added
  • Sending a create request while an identical one, with the same idempotency key, is still being processed
Examples:
How to fix:
  • For a paused monitor, resume it with POST /monitors/{monitor_id}/update and "is_active": true, then trigger it
  • For a monitor whose status is starting, wait until it is active. For one whose status is failed, send the same upload request again, with the same file and settings, to finish it
  • A cancelled monitor cannot be resumed or changed. Create a new monitor to start checks again
  • For an idempotency conflict, retry with the original creation payload, or use a new key for a new monitor
  • If the request is still being processed, retry after a few seconds with the same payload and key; it returns what the first attempt created

409 Conflict (Atlas)

POST /people-intelligence-async with exclusive_run: true on an existing investigation returns 409 while that investigation already has a run starting or running. Wait for the current run to finish, then retry. POST /v1/atlas/investigations/{investigation_id}/runs has no exclusive_run option.
Starting a run or requesting a report while the investigation is being deleted also returns 409: Atlas investigation is being deleted or investigation is being deleted.

409 Conflict and 428 Precondition Required (Workflow Edits)

An existing workflow content update requires expected_revision, copied from the latest workflow read’s edit_revision. Missing it returns 428 with detail.code: "workflow_revision_required". A stale revision returns 409 with detail.code: "workflow_draft_conflict", current_revision, and the current workflow in current_workflow. Nothing from the stale update is saved. Apply your changes to current_workflow and resend with current_revision as expected_revision. Resending the old definition with the new revision overwrites the other edits. Updating a deleted workflow returns 404. Changing the blocks of a locked workflow returns 409 (Workflow is locked. Unlock it before changing its blocks.); name and description changes still apply. A run with expected_revision returns 409 if the revision changed (workflow_draft_conflict) or the workflow has a draft that failed validation (workflow_draft_not_runnable). No new run starts for either refusal.

409 Conflict (Workflow Runs)

POST /workflows/create_workflow with an id already in use, and a run of a workflow with no valid saved definition, also return 409.

413 Content Too Large

Causes:
  • A /storage/csv/upload file larger than 45 MB: Tabular files must be 45MB or less
  • A workflow definition past its size or block-count limit, with detail.code workflow_definition_too_large
  • A monitor handle_id file larger than the monitor upload limit: Uploaded file exceeds the monitor upload size limit.
  • A monitor history export that is too large: History export is too large. Select fewer dates. or Too many snapshots. Select a smaller date range.
Nothing is saved or started. Send a smaller file, definition, or date range.

422 Validation Error (Monitors)

POST /monitors/{monitor_id}/update returns 422 for any request containing struct, even null or the current definition, and applies nothing. To change watched fields, create a new monitor. POST /monitors and POST /monitors/{monitor_id}/update return 422, with a field-level detail array, when webhook_event_types is empty or names an unknown event. See Monitor Endpoints.

422 Validation Error (Workflows and Other Monitor Requests)

Causes:
  • A workflow name, description, block field, or spec value past its limit, or a block name that does not exist, with detail.code workflow_field_too_long and one validation_errors entry per value
  • Missing required fields in create/update requests
  • Unknown fields in monitor create, update, row-toggle, source, or history-export JSON requests, such as frequncy instead of frequency
  • Toggling a monitor row without the required JSON body {"is_active": false} or {"is_active": true}; the query parameter alone is not accepted
  • A monitor handle_id that is not a tabular upload: Use a tabular upload handle from /storage/csv/upload.
  • A cursor for GET /monitors/for-run/{run_id} that did not come from a previous response: Invalid monitor page cursor.
Example:
How to fix:
  • Shorten each value named in validation_errors
  • Check block compatibility (e.g., webhook → company_enrichment)
  • See GET /workflows/blocks for block specs

429 Too Many Requests

A request went over a rate or concurrency limit and did not run. Retry after the Retry-After header. See Rate Limits.

500 Internal Server Error

Example:
A sync People Intelligence, Company Intelligence, or QA Agent request also returns 500 when its job fails after it was accepted, for example when the balance no longer covers it or a micro request asks for more than 10 fields. The -async endpoints report the same failure as a failed job. Failed to fetch user organization from API key means the API key could not be checked. Retry the request. How to fix:
  • Retry the request with exponential backoff
  • If the error persists, contact support@sixtyfour.ai with the response’s correlation_id

502 Bad Gateway

503 Service Unavailable

Sixtyfour is briefly unavailable or at capacity. Requests refused before they run are not charged. Retry after the Retry-After header. For POST /workflows/run, a 503 with code workflow_input_unavailable means the run’s input could not be kept or read within the 15-second limit for preparing the run’s input. No run was started and nothing was charged. Retry after Retry-After with the same body. If the message says saved rows failed their integrity check, replace the input rows or contact support. While saving input is only slow, the run still starts, as long as the input is kept within that limit.
For POST /workflows/cancel, a 503 means the cancellation is not confirmed. Retry the cancel for the same job_id and poll live status until the run ends. Do not start another run. The -async endpoints never return the capacity 503; their jobs wait. See Async Jobs.

Filter field values errors

POST /search/filter-field-values puts a code in detail:

Monitors

These requests return 400. See Monitor Endpoints. Two rows with the same key values:

Signed download URLs

A download_url from workflow results or webhooks, and the url from GET /search/download, needs an API key or OAuth token from the same organization. Downloads share an organization budget; see Rate Limits.

Workflow result download retries

GET /workflows/runs/{run_id}/results/download-links returns 429 or 503 with Retry-After. Wait that long and send the same request. Neither response affects the run or its results, so do not start a new run to recover a download. See Rate Limits.

Private runs

Lattice

Webhook test events

No webhook is sent for any of these.

Feedback

A request with no comment, rating or corrections, corrections without task_id, dispatch_id or workflow_row, more than one of those three, a field corrected twice, a source_url that is not http or https, text holding the NUL character, or more than 256 KB of JSON returns 422. Nothing is saved for any of these.

Skills

Nothing is saved or started for any of these.

Connections

Nothing is saved, sent or started for any of these. Error responses never repeat the secret.

LinkedIn monitor validation and access

LinkedIn monitor check failures

A LinkedIn monitor accepts any valid profile URL. A profile Sixtyfour has no data for reports a row error event on each check: A failed check keeps the previous baseline and reports no changes; the next scheduled check tries again. See LinkedIn Monitors. A LinkedIn check that fails because the balance is too low writes no error event. It sends monitor.execution.failed instead.

Common Troubleshooting Scenarios

Issue: Request times out

Research calls take up to 10 minutes. Set your client timeout to at least 15 minutes, or use the -async endpoints with polling or webhook_url. A sync request keeps running, and is charged, after your client disconnects; see Sync calls and retries.

Issue: Empty or incomplete results

Send more identifiers (name, company, LinkedIn URL) and specific struct descriptions; check confidence_score.

Issue: Workflow run stuck or not progressing

Check:
  • Are you polling GET /workflows/runs/{run_id}/live_status?
  • Is the overall_status still queued, running, or finalizing?
Solution:
  • Poll every 10 seconds or slower and honor Retry-After. See Status polling
  • Any overall_status other than queued, running and finalizing is final
  • Use overall_progress_percentage and blocks to see per-block progress
  • To stop a run: POST /workflows/cancel?job_id={job_id}
  • Check each block’s error_message. Cancel and rerun a run that stops progressing

Issue: Webhook signature verification fails or deliveries stop

Check:
  • Is your verifier using the raw request body bytes, not a re-serialized JSON parse?
  • During rotation, does it iterate every v1= segment (not only the last)?
  • Is your server clock within 5 minutes of UTC?
  • Are you using the plaintext secret (sk_whsec_<64 hex>), not the masked preview shown in the dashboard?
Solution:
  • Log the raw body, the Sixtyfour-Signature header, and the HMAC your server computes; compare against what we sent.
  • See Signing Secrets & Verification for the verification algorithm and reference code.
  • When your organization has a signing secret and Sixtyfour cannot sign a delivery, it sends nothing. Results stay available at GET /job-status/{task_id}.

Verify Phone column mappings

Rows with a phone but no value in the configured name_column skip verification without failing the batch. They return Missing Name in phone_warnings and MissingRequiredInput details in phone_errors. The name mapping must match the input column. For example, data containing fullName requires name_column: "fullName". See Verify Phone to update a saved mapping. A missing phone column fails the block; a blank phone value skips the row.

Getting Help

If you’re experiencing issues not covered in this guide:
  1. Check the endpoint’s page for its requirements; the quick start lists every area
  2. Check status.sixtyfour.ai for incidents
  3. Contact support at support@sixtyfour.ai
  4. Include the following in your support request:
    • The correlation_id from the response
    • Request/response details (remove sensitive data)
    • Error message
    • Endpoint being called
    • Approximate timestamp of the error