Audit events help reconstruct account activity, while notifications draw attention to operational items that may need action. Treat them as complementary evidence. Marking a notification as read does not resolve the underlying job, restore a service or approve a domain change.
| Method | Resource | Scope | Idempotency-Key |
|---|---|---|---|
GET |
/v2/audit-events |
logs:read |
Not required by this route |
GET |
/v2/notifications |
profile:read |
Not required by this route |
POST |
/v2/notifications/{notificationId}/read |
profile:write |
Required |
01 Build an account activity view
- Use an appropriately restricted credential. Audit access requires
logs:read; notification reading and acknowledgement use their separate profile scopes. - Page through audit events and use the supported search field when narrowing an investigation. Preserve the event ID, time, actor, resource and request reference that the response actually provides.
- Correlate the event with the current domain, DNS changeset, order or forwarding deployment. Distinguish who requested work from whether the provider completed it.
- Read notifications and show the relevant account user a clear action or support reference.
- After the user has reviewed a notification, POST to its
readresource with an idempotency key and update your local display from the response.
02 Keep evidence useful and private
Do not turn a broad log reader into a public dashboard. Account ownership and permissions still restrict resources, and integration logs should exclude API keys, authentication signatures, verification codes and unnecessary contact data.
Keep a consistent timezone when comparing API events with billing-platform logs. An actor's local browser time can otherwise make a legitimate sequence appear reversed. Preserve the original request ID rather than relying on a screenshot of a shortened message.
Common questions
Does an audit entry prove the provider accepted the change?
It proves only the event represented by that entry. Check the related operation's state and provider reference for completion evidence.
Can marking a notification read dismiss an error?
It changes the notification's read state. A failed renewal, incomplete DNS job or account hold must be addressed through its own workflow.
What if an event appears unfamiliar?
Compare the actor, credential label, affected resource and source information with authorised integrations and staff activity. If access appears unauthorised, preserve evidence, secure the relevant account and rotate the affected credential through the supported process.
For a support escalation, provide a small, relevant event sequence and resource references. Avoid exporting unrelated customer activity merely because the same account can read it.
Related articles
- Diagnose API permission errors using the profile and capability endpoints
- Rotate Domain Nexus API credentials across web and scheduled integrations
- Follow a domain operation through pending, failed and manual-review states
- Inspect webhook failures and replay one delivery safely
- Reconcile registrar provider events against an existing transaction