Open-source contribution is not always about adding another feature to a project. Sometimes, it is about making an existing system work with tools that people already use every day.
Recently, I worked on adding Cisco Webex support to Switch, an open-source platform that enables AI agents to collaborate through messaging applications.
This contribution is part of the Switch Hackathon by WeMakeDevs.
In this article, I want to share what I built, some of the engineering challenges involved, how I approached the integration, and what I learned along the way.
1. Understanding the problem
Switch already provides a foundation for connecting AI agents with messaging platforms.
However, there was an opportunity to extend that experience to Cisco Webex.
Webex is used by organizations for team communication, direct conversations, and collaboration. Bringing AI agents into this environment can make them more accessible to teams without requiring people to switch between multiple applications.
The original feature request was:
Add Webex as a messaging platform.
GitHub Issue: https://github.com/sandbox-quantum/switch/issues/795
The goal was to implement a Webex integration that allows users to connect their own Webex bot credentials through Switch and communicate with their AI agents.
2. Understanding the integration architecture
Before implementing the adapter, I needed to understand how Switch handles messaging platforms.
The important parts of the integration included:
- Webex bot authentication and credentials.
- Webhook-based event delivery.
- Mapping Webex spaces to Switch conversations.
- Supporting direct messages and group spaces.
- Maintaining thread context.
- Handling attachments and interactive approval actions.
I chose a webhook-based approach for receiving events from Webex.
This allows Webex to send events to a per-connection endpoint exposed by Switch.
The integration then translates incoming Webex events into the message format expected by Switch.
3. Building the Cisco Webex adapter
The implementation focuses on making Webex behave like a native messaging platform within Switch.
Some of the important capabilities include:
Direct and group conversations
The adapter handles both one-to-one conversations and group spaces, mapping them into the appropriate Switch conversation types.
Threaded replies
Webex uses parent message identifiers to associate replies with their original messages. The adapter preserves this relationship so that conversations remain organized.
Message chunking
Long responses need special handling because messaging platforms impose message-length limits. The adapter splits long content into manageable chunks.
File attachments
The implementation supports multipart attachment sending and secure file streaming when receiving attachments.
Interactive approval actions
Webex interactive card actions can be used to submit approval decisions back to Switch.
These features are important because an AI integration should support more than just sending and receiving plain text.
4. Security was an important part of the implementation
Messaging integrations process external requests and potentially untrusted data. Security cannot be treated as an afterthought.
I included several protections in the implementation:
- HMAC signature verification using supported SHA algorithms.
- Replay-attack checks for incoming webhook requests.
- IP validation to help prevent server-side request forgery (SSRF) during file downloads.
- A 100 MB download cutoff.
- Credential verification during connection setup.
The goal was to make the adapter more robust when dealing with incoming webhook events and external file resources.
5. Fixing an additional Windows compatibility issue
During the contribution, I also addressed a small but important compatibility issue.
The connection loader's frontmatter regular expression needed to account for Windows CRLF line endings.
I updated the matching logic to support both Unix-style and Windows-style line endings.
This was useful because developers should be able to work with the project across different operating systems without encountering avoidable parsing issues.
6. Testing the implementation
An integration is not complete just because the code compiles.
I added a dedicated unit test suite covering different adapter scenarios.
The submitted implementation reports 25 passing unit tests, covering:
- HMAC signature verification.
- Different signature algorithms.
- Replay protection.
- Webhook event routing.
- Direct and group conversation handling.
- Threaded replies.
- Interactive card submissions.
- Attachment download and upload handling.
- SSRF protection and download limits.
- Message chunking.
- Credential verification.
I also performed a live bot smoke test by connecting a Webex bot to the local Switch server through the webhook endpoint.
The reported validation results were:
25 passed in 0.51s
Ruff: 0 errors
Pytest: 25/25 passing
These results are from the submitted PR's test report.
7. My contribution to Switch
I submitted the implementation through:
Pull Request #1027: feat(messaging): add Cisco Webex collaboration bridge adapter
PR: https://github.com/sandbox-quantum/switch/pull/1027
The current PR contains:
- 8 changed files.
- 1,541 additions.
- 1 deletion.
- A dedicated Webex adapter.
- A test suite.
- Webex integration documentation.
- A Windows CRLF compatibility fix.
The pull request is currently open and awaiting review.
I am looking forward to feedback from the maintainers and the opportunity to improve the implementation further.
8. What I learned
This contribution helped me understand that integrating a messaging platform involves much more than connecting two APIs.
Some important lessons:
Understand the existing architecture first.
Following established adapter patterns makes integrations easier to maintain and keeps new features consistent with the rest of the project.
Think about edge cases early.
Thread relationships, message limits, duplicate events, attachments, and webhook validation all matter in a production-oriented integration.
Testing should cover behavior, not just successful requests.
Security checks and failure scenarios deserve dedicated tests.
Documentation is part of the implementation.
A feature is more useful when another developer can understand how to configure, test, and maintain it.
9. Closing thoughts
Working on Cisco Webex support for Switch has been a valuable open-source engineering experience.
It gave me the opportunity to explore messaging infrastructure, webhook integrations, security validation, Python testing, and the architecture of an AI agent collaboration platform.
I am grateful for the opportunity to contribute through the WeMakeDevs Switch Hackathon and to work on an integration that can make AI agents accessible through another collaboration platform.
This is one more step in my journey of learning by building, contributing to open source, and solving practical engineering problems.
Code is only one part of the contribution. Understanding the problem, handling edge cases, testing the implementation, and documenting the result matter just as much.
Useful links
- Pull Request: https://github.com/sandbox-quantum/switch/pull/1027
- Original Issue: https://github.com/sandbox-quantum/switch/issues/795
- Switch Hackathon: https://www.wemakedevs.org/hackathons/switch
- Switch Repository: https://github.com/sandbox-quantum/switch
Top comments (0)