Update a note
/notes/{note_uuid}
Update a note's text. Only note_text can be changed - the note's parent entity, parent
event, author and archive state are all immutable from the API. To "move" a note to a
different entity or event, delete it and re-create.
Example Request
PATCHRequest Schema
note_uuid
The note UUID
note_text
Replacement text for the note. Max 5000 characters.
Available Response Data
12 Data Pointsuuid uuid
The note's UUID
note_number string (A short obfuscated public identifier for the note (e.g. "N-A1-B2C-3D4"))
note_text string (The free-text content of the note (max 5000 characters))
created_by object
Identifies who created the note
is_immutable boolean
When true, the note is an immutable audit-trail entry and cannot be edited or
entity_uuid uuid
UUID of the entity this note is attached to
program_uuid uuid
UUID of the program the entity belongs to
event_uuid uuid
UUID of the event this note is attached to, if any
archived_at timestamp (ISO 8601 timestamp at which the note was archived in the portal (null if not archived))
created_at timestamp
updated_at timestamp
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
Propagating changes from your system of record
Push corrections and changes of circumstance into WatchEye as they happen, so screening runs against current details, not the details captured at onboarding.
Status and lifecycle management
Change status fields as a matter progresses. A status change is not a deletion, so the record stays fully visible through the API.
Keeping the audit trail intact
Every update is written to the account audit log, so the change history is available without you maintaining a parallel record of 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 Update a note?
Talk to our team about credentials, sandbox access and the right combination of endpoints for your workflow.