Skip to content
Notifications
Clear all

We built a custom integration for Zendesk - here's the code

1 Posts
1 Users
0 Reactions
3 Views
(@chris)
Reputable Member
Joined: 1 week ago
Posts: 127
Topic starter   [#18142]

Our team recently completed a quarterly review where we identified a significant gap in our support ticket observability. While Sumo Logic provided excellent insights into our application logs, metrics, and traces, correlating this data with Zendesk ticket metadata required manual, error-prone cross-referencing. The native integration options were either too generic or didn't map our custom ticket fields vital for SLA tracking and incident root cause analysis.

Therefore, we engineered a custom, event-driven integration using Sumo Logic's HTTP Source and AWS Lambda. The architecture subscribes to Zendesk webhooks, enriches the ticket data with relevant application performance metrics queried from Sumo Logic's API, and forwards a structured JSON payload to our logs. This allows us to run queries like:
```
_sourceCategory=zendesk/integration "priority"="high" | timeslice 1h | count by _timeslice, `app_deployment_region` | transpose
```
To visualize high-priority ticket volume against deployment region health.

The core Lambda function (Node.js 18.x) handles authentication, data enrichment, and error retry logic. Below is the key section where we fetch the related error rate from Sumo for the service tagged in the Zendesk ticket before constructing the final event.

```javascript
async function enrichWithSumoMetrics(ticket) {
const sumoQuery = `_sourceCategory=app/prod/${ticket.service_name}
| where %"error_code" is not null
| timeslice 5m
| count as errors by _timeslice
| compare with timeshift 30m`;

const sumoResponse = await executeSumoLogicQuery(sumoQuery);
const errorTrend = calculateTrend(sumoResponse.results);

return {
...ticket,
observability_context: {
error_count_5m: sumoResponse?.latest_count || 0,
error_trend_30m: errorTrend,
query_link: generateQueryLink(sumoQuery)
}
};
}
```

We encountered several challenges requiring meticulous benchmarking:
* **API Latency:** The sequential processing of webhook -> Sumo query -> ingestion added ~1200ms p95 latency. We mitigated this by implementing a non-blocking design where the webhook acknowledges receipt immediately, and processing happens asynchronously.
* **Cost Management:** Uncontrolled Sumo API query volume from high ticket throughput. We added a caching layer for frequent service names and a circuit breaker to skip enrichment during known outages.
* **Data Schema Versioning:** We enforce a strict schema using JSON Schema validation at the HTTP Source to prevent malformed data from polluting our logs.

The integration now processes an average of 850 tickets daily. The enriched data has reduced our Mean Time to Resolution (MTTR) for infrastructure-related tickets by approximately 22% over the last quarter, as we can immediately correlate ticket bursts with deployment events or error spikes. We are considering open-sourcing the full codebase, including the Terraform modules for AWS provisioning, if there is community interest.

—chris


—chris


   
Quote