Unarchive an entity
/entities/{entity_uuid}/unarchive
Restores an archived entity together with all of its checks, reports, events, notes and
identification checks. The entity returns to the active set and resumes appearing in
monitor runs and default reports.
Calling unarchive on an entity that is not currently archived returns the entity in its
current state without recording a new audit entry or re-cascading to the child records.
Example Request
POSTRequest Schema
entity_uuid
The entity UUID
Idempotency-Key
Optional client-generated key (typically a UUID) that lets you safely retry a write request without risk of duplicate work or duplicate billing. A retry with the same key and body returns the original response verbatim, with the `Idempotent-Replay: true` response header. Honoured on `POST` requests
Available Response Data
13 Data Pointsuuid uuid
The entity's UUID
entity_number string (A short obfuscated public identifier for the entity (e.g. "E-A1-B2C-3D4"))
reference_number string
An optional customer-supplied reference number, unique within the program
entity_type enum
The type of entity: individual, business, vessel, property
entity_name string
The display name of the entity, computed from the relevant type-specific fields
first_name string (First name (individuals only))
middle_name string (Middle name (individuals only))
last_name string (Last name (individuals only))
birth_date string (Date of birth in YYYY-MM-DD format (individuals only))
business_name string (Business name (businesses only))
business_number string (Business identifier (businesses only); format depends on business_number_type)
business_number_type enum
The type of business_number: au_abn, au_acn, uk_crn, other
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
Take an entity out of active screening
Archive an entity when the relationship ends, so it stops consuming monitor runs while its history stays intact.
Reversible
Archiving is reversible through the matching unarchive endpoint.
Retained indefinitely
Archived records are not subject to the 30-day deletion window, which makes archiving the right choice where compliance requires the record to persist.
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
Is it safe to retry this call?
add
Is it safe to retry this call?
Yes, if you send an Idempotency-Key header. A connection can drop after WatchEye has processed a request but before the response reaches you, and a blind retry would risk a duplicate record or a double charge.
The key is any string of your choosing up to 255 characters, unique per logical operation, and a fresh UUID per request is the usual approach. Sending the same key again returns the original response byte for byte, with no new database changes and no new billable charge.
The header is honoured on POST only. It is silently ignored on GET, PATCH and DELETE, which are already idempotent at the HTTP level.
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 Unarchive an entity?
Talk to our team about credentials, sandbox access and the right combination of endpoints for your workflow.