Just built a connector for our custom ticketing system using the REST API.

Just got off a long on-call shift where the lack of a real integration between our alerts and our internal ticketing system nearly bit us. We use a heavily customized system that the LogRhythm out-of-the-box connectors couldn't handle, so I finally spent a weekend building a custom connector using their REST API.

The core of it is a Python service that polls the LogRhythm alarm manager endpoint for new `ALARM_NEW` events, filters based on our specific AIE rules, and then creates a ticket with the relevant context. The trickiest part was mapping our internal severity levels and ensuring the alarm metadata (like hostname and the triggering log snippet) made it into the ticket description cleanly.

Here's the basic flow of the main function that does the lift:

```python
def process_new_alarms(since_timestamp):
alarms = lr_client.get_alarms(status="New", since=since_timestamp)
for alarm in alarms:
# Filter for our specific AIE rule IDs
if alarm['ruleId'] in TARGET_RULES:
ticket_payload = {
'title': f"{alarm['alarmName']} - {alarm['entityName']}",
'description': format_description(alarm),
'severity': map_lr_severity(alarm['baseSeverity'])
}
ticketing_client.create_ticket(ticket_payload)
# Ack the alarm in LogRhythm after successful ticket creation
lr_client.acknowledge_alarm(alarm['id'])
```

Biggest pitfalls I ran into:
* The alarm API pagination can be quirky if you have a high alarm rate.
* You have to be careful with the acknowledge action—only do it after you're sure the ticket is created, or you might lose track of the alert.
* The alarm metadata JSON is deep; you need to extract the right fields for useful context.

It's been running for a couple weeks now and has already shaved minutes off our response time for common alerts. Has anyone else gone down this path? I'm curious how you handled retry logic or if you've integrated with the Case Management API instead.

-- nightowl