Show an adhoc check
/adhoc-checks/{adhoc_check_uuid}
Returns a single adhoc check by its UUID, including:
* The base envelope (created_by, outcome, timestamps, etc.) - same shape as the
list endpoint
* results_overview[] - one row per result, with a uniform {title, status, alert_ids}
shape across all operation types
* children[] - per-child summaries when the check is a group; empty otherwise
* details - the typed per-operation details block.
Example Request
GETRequest Schema
adhoc_check_uuid
The adhoc check UUID
Available Response Data
13 Data Pointsuuid uuid
The adhoc check's UUID
check_number string
A short obfuscated public identifier for the adhoc check
check_type string (The type of check that was run (see AdhocCheck.check_type))
check_type_name string
Display name for the check type
status enum (Lifecycle status of the adhoc check (see AdhocCheck.status): pending, processing, complete, failed)
failed_reason string (Short reason why the check failed (see AdhocCheck.failed_reason))
outcome enum (High-level outcome of the check (see AdhocCheck.outcome): pass, warning)
check_summary string
Short, human-readable summary of the result
data_summary string
Short, human-readable summary of the subject the check ran against
checked_at timestamp
created_by object
Actor who launched the adhoc check - see AdhocCheck.created_by
parent_uuid uuid
api_reference uuid
unique request identifier for log tracing and audit
API Data Scale & Coverage tag
Unmatched data depth to power your compliance and verification workflows.
Sandbox Environment
Build and test against a sandbox account. Sandbox is a separate account with its own UUID and its own API keys, and the environment is fixed at the account level, so you cannot switch an existing key between live and sandbox with a parameter or header. Both share the same base URL, so the account behind your key is what determines which environment you are in. GET /v1/account returns an environment field of live or sandbox, and that is the authoritative answer.
Calls on a sandbox key are not billed. Every endpoint, response shape, error envelope, idempotency and rate-limit behaviour mirrors live, so the only change when you move to production should be the credentials. Sandbox accounts are provisioned by your Global Data account manager.
Technical Use Cases tag
Detail view in your own UI
Fetch the full adhoc check record by UUID to render a detail screen inside your own application, so staff never need a second system open.
Evidence for a decision record
Retrieve the stored adhoc check at the point a decision is made and attach it to your case file, with the api_reference value recorded for log tracing.
Support and reconciliation
Resolve a single UUID when investigating a discrepancy, without paging a list endpoint to find it.
Compliance & Security tag
Enterprise-grade infrastructure audited against the standards your regulators require.
Common Questions tag
Everything you need to know about implementation details and compliance infrastructure.
rocket_launch Implementation
What are the rate limits?
add
What are the rate limits?
600 requests per minute by default, enforced with a 60-second fixed window. Every response carries X-RateLimit-Limit and X-RateLimit-Remaining.
Exceeding the limit returns 429 Too Many Requests with a Retry-After header giving the number of seconds to wait, and X-RateLimit-Reset giving the reset timestamp. Schedule retries from Retry-After instead of a fixed sleep, and slow down before you hit zero, not after.
Higher limits can be arranged case by case through WatchEye support.
Ready to integrate Show an adhoc check?
Talk to our team about credentials, sandbox access and the right combination of endpoints for your workflow.