Use case:
We are building an integration between PRTG and our monitoring platform that requires tracking individual sensor event occurrences through their complete lifecycle (open → close). Currently, there is no way to uniquely identify the same event occurrence across both real-time notifications and the API messages endpoint.

Our integration needs to:
1. Capture event creation: When a sensor goes DOWN (or WARNING), create an event record in our system
2. Track event resolution: When the same sensor recovers (goes UP), update the same event record to mark it as resolved
3. Maintain historical tracking and allow Synchronization for missed events through API.
Current Limitation:
The /api/table.json?content=messages endpoint provides a unique objid for each message, which identifies individual event occurrences. However, this same objid value is not available as a notification placeholder for Execute Program notifications. And potentially gives a different id per event update.
This creates a fundamental integration problem:
- API sync can retrieve message objid: 5428 for a DOWN event
- Webhook notification for the same event has no way to reference objid: 5428
- We cannot correlate the webhook notification with the API message
Why the Suggested Workaround Doesn't Work ("...you can combine placeholders such as (%sensorid & %datetime & %status) to create a reasonably unique identifier."):
The suggested approach of using %sensorid%-%datetime%-%status% has critical flaws:
Issue 1: Timestamps change during event lifecycle
DOWN event fires at 14:30:00 → Webhook sends: "2092-2025-01-02-14:30:00-Down"
UP event fires at 14:35:00 → Webhook sends: "2092-2025-01-02-14:35:00-Up"
Result: Different IDs for the SAME event occurrence → Cannot close the event
Issue 2: Synchronization timing mismatch
Notification fires at 14:30:03.245
API sync runs at 14:30:07.891
Webhook creates: "2092-2025-01-02-14:30:03-Down"
API returns: "2092-2025-01-02-14:30:03-Down" (from message datetime field)
Result: Cannot match webhook to API message
Issue 3: Only shows latest state per sensor
Using %sensorid% alone:
- Monday DOWN → Event "2092" created
- Monday UP → Event "2092" closed ✓
- Tuesday DOWN → Event "2092" reopened (overwrites Monday's data) ✗
Result: No historical tracking of separate incidents
Proposed Solution:
Expose the existing message/event objid value as a notification placeholder (e.g., %messageid% or %objid%).
Why This Works:
The message objid is generated by PRTG when logging state changes. We simply need access to this same value in notifications ( and of course be able to identify an event uniquely ):
When sensor goes DOWN:
- PRTG logs message with objid=5428
- Notification template receives: %messageid% = 5428
- API endpoint /api/table.json returns: {"objid": 5428, "status": "Down"}
- Both use identical ID: 5428 ✓
When sensor goes UP:
- PRTG logs message with objid=5429
- Notification template receives: %messageid% = 5429
- API endpoint /api/table.json returns: {"objid": 5429, "status": "Up"}
- Both use identical ID: 5429 ✓
Alternative Solution:
If exposing message objid is not feasible, add a %triggerid% placeholder that returns the notification trigger ID. And return this triggerid in Api calls for synch too. This would allow constructing: sensorid-triggerid-server state, though this is less optimal as it requires additional logic.
Benefit to PRTG Users:
This enhancement would enable proper event lifecycle tracking for:
- External integrations and SIEM systems
- Ticketing platforms
- Event management systems
- Historical incident tracking
- MTTR (Mean Time To Resolution) calculations
Request:
Please expose the objid/eventid value as a notification placeholder (e.g., %messageid% or %objid%). This would provide parity between the API and notification system, enabling proper event lifecycle tracking for external integrations.

From my understanding in the API the objid is actually just the id of the message sent and doesn't indicate to what event the message/event belongs to. So my request is also relevent for the Api - show the Event ID ( so we can also know what to resolve ) or the workaround is showing the Trigger ID to create a accurate composite key with Sensor and Server.

Thank you for considering this enhancement!
Best Regards,
Daniel