The Problem: Two Worlds, Zero Communication
If you’ve ever worked in a company where customer support uses Freshdesk and engineering uses GitHub, you know the pain. Support agents create tickets. Engineers work on issues. And somehow, these two systems never talk to each other.
The result? Chaos.
Support agents constantly ping engineers asking for updates. Engineers have to manually copy ticket details into GitHub issues. When something ships, nobody remembers to update the original ticket. Customers wait longer than they should for answers.
I faced this exact problem at work. Our support team lived in Freshdesk. Our engineering team lived in GitHub Projects. The handoff between them was a mess of Slack messages, forgotten updates, and frustrated people on both sides.
So I decided to fix it.
What I Built
I created an automated bidirectional sync system that bridges Freshdesk and GitHub. Here’s what it does:
Automatic Issue Creation
When a support ticket reaches “To Pick” status (meaning engineering needs to look at it), my system automatically creates a corresponding GitHub issue. It pulls the ticket details, maps the priority (P0-P3), assigns it to the right engineer based on a product mapping, and adds it to our GitHub Project board.
Real-Time Comment Sync
This is where it gets interesting. Comments flow both ways:
- When an engineer adds a comment on GitHub, it appears as a private note in Freshdesk
- When an agent adds a note in Freshdesk, it shows up on the GitHub issue
- Even inline images sync properly—whether they’re in Markdown or HTML format
Support agents can now see engineering progress without leaving Freshdesk. Engineers can respond without leaving GitHub.
Status Synchronization
When an engineer moves a GitHub issue through the project board (In Progress → Code Review → Live), the Freshdesk ticket status updates automatically. No more “hey, is this done yet?” messages.
Smart Notifications via Slack
The system sends contextual Slack DMs:
- Engineers get notified when they’re assigned a new issue
- Agents get notified when their tickets reach final states (“Live on Production” or “Dropped”)
Edge Case Handling
Real-world systems have edge cases. I built handlers for:
- Reopened tickets: If a ticket is reopened after reaching a “final” state, the system detects this and resumes syncing
- Direct closures: If an agent closes a Freshdesk ticket directly, the corresponding GitHub issue gets closed too
- Rate limiting: Both Freshdesk and GitHub have API limits. The system uses exponential backoff to handle this gracefully
The Technical Stack
- Python for the core logic
- GitHub GraphQL API for creating issues and managing project boards
- Freshdesk REST API for ticket operations
- Google Cloud Storage for configuration and state management (CSV tracking, sync state)
- Slack API for notifications
- Docker for deployment
Why This Matters
This wasn’t just a “nice to have” automation project. It fundamentally changed how our teams work together:
- Zero context switching: Engineers never have to open Freshdesk. Agents never have to check GitHub.
- Automatic accountability: Every ticket has a paper trail. Every status change is tracked.
- Faster response times: When an engineer comments on an issue, the agent sees it immediately.
- No more lost tickets: The system maintains a CSV of every ticket-to-issue mapping, so nothing falls through the cracks.
Lessons Learned
Building this taught me a few things:
Rate limiting is real. Both Freshdesk and GitHub will throttle you. I added exponential backoff with up to 10 retries for critical operations. The system uses multiple Freshdesk API keys and rotates between them to maximize throughput.
State management is harder than it looks. Tracking which comments have already been synced, detecting reopened tickets, handling concurrent updates—all of this requires careful state management. I ended up using a combination of GCS-hosted JSON files and CSVs to maintain sync state.
Edge cases multiply. What happens when someone adds an image to a GitHub comment? What if a ticket is reopened? What if the API is down mid-sync? Each edge case led to another 50-100 lines of handling code.
The Result
What started as a weekend project to solve an annoyance became a production system that runs continuously, syncing hundreds of tickets between our support and engineering teams.
The best compliment I received? A support agent told me they forgot we even used two different systems.
That’s the goal of good automation—it becomes invisible.
If you’re facing a similar integration challenge, feel free to reach out. The concepts here apply to any two-system sync problem.