Simplifying Google Calendar + Telegram Integration: A Developer's Guide

As the world becomes more and more agentic, it’s important to meet your users where they are, and this usually means providing them with polished UX in whatever communication platforms they use on a daily basis:

• WhatsApp
• Email
• Telegram
• Discord
• Slack

Adding a chatbot experience to chat-like interfaces is usually pretty easy. I just pick one of the existing LLM clients, add my API Key, a nice system prompt, and let users chat away. However, things quickly become complex if the agent needs to actually do things, especially if it needs to do things on behalf of my users. All of a sudden, I need to handle not only the interactions with the LLM, but also tool calling, and the authentication and authorization related to every tool the users need. All of this while thinking on the specific UX considerations of that specific communication channel. This is clearly difficult to scale if I want to meet my users wherever they may be.

Fortunately, Arcade offers an agentic-first approach that lets me delegate this complexity to the “agentic layer” and focus on polishing the UX.

I put out a video where I redesign a Telegram bot designed to schedule Google Calendar events based on natural language input, powered by Groq's speedy LLM. The original implementation, while functional, is a prime example of "traditional" agent architecture complexity. By integrating the Arcade client, I reduced the number of lines a little bit (which is nice), but most importantly, I removed the need to maintain the auth and Google API integrations for the bot.

The "Before": Small codebase with signs of complexity creep

The initial setup involves:

1. Telegram Bot Framework: Handling incoming messages and user interactions.
2. Groq API Calls: Sending user input to the LLM for intent recognition and entity extraction (like dates, times, event titles).
3. Google Calendar API: The real beast. This required:
   • Implementing the full OAuth 2.0 flow to get user permission.
   • Securely storing access and refresh tokens.
   • Handling token expiration and refresh logic.
   • Making carefully crafted API calls to list calendars, check availability, and create events.
   • Parsing the often complex responses from the Google API.

Each piece is manageable on its own, but wiring them together can become fragile as the system becomes more complex. Auth, in particular, can be a significant and constant source of potential bugs and security concerns. Debugging involves tracing calls across multiple services. And adapting this intricate dance for another platform like Slack or WhatsApp? That’s where scaling the product becomes an issue.

This is a small codebase and already the architectural complexity is high, especially if we plan to support more platforms in the future.

The "After": Focused architecture

At a superficial level, the changes are not very dramatic:

• Add the Arcade JS client as a dependency
• Remove Express and Google (we don’t need to host a server anymore!)
• Adapt some of the types to match Arcade’s Google Calendar integration
• Add (and call) the following utility function:

const authArcade = async (chatId: number): Promise<{ logged_in: boolean, url: string }> => {
    const authResponse = await arcade.auth.start(
        chatId.toString(),
        "google",
        {
            scopes: ["https://www.googleapis.com/auth/calendar.readonly", "https://www.googleapis.com/auth/userinfo.email"],
        }
    )
    if (authResponse.status !== "completed") {
        return { logged_in: false, url: authResponse.url || "ERROR: No URL returned" };
    }
    return { logged_in: true, url: "" };
}

(yes, that’s the entire auth)

• Replace the API call with Arcade’s direct tool calling
• Run the bot

The Results: More Than Just Fewer Lines of Code

Yes, the line count dropped, which is always satisfying. But the real win was the reduction in complexity:

1. Simplified architecture: The entire burden of OAuth and direct API interaction for Google Calendar vanished, abstracted away by the Arcade client.
2. Improved Maintainability: The core logic of the bot is now much cleaner and easier to understand. Debugging is simpler because the interaction with external tools happens through a single, consistent interface. Now the maintainer can focus solely on improving the UX for this one platform without worrying about breaking auth or tool calling for the agent.
3. Effortless Extensibility: This is huge. Want to add Slack support? Or WhatsApp? The logic interacting with Groq and Google Calendar via the Arcade client doesn't need to change. I only need to handle the message input/output for the new platform. Arcade provides the stable bridge to the tools, regardless of the frontend.

Conclusion: Focus on Value, Not Plumbing

By replacing the complex, bespoke API and authentication handling with the Arcade.dev client, I transformed the original code into something streamlined and adaptable, less prone to complexity creep. It allowed me to focus on the agent's core value – understanding user requests and interacting with their calendar – rather than getting bogged down in the plumbing of external service integrations.

You can try out the bot yourself by creating an Arcade account, and cloning the repo. Happy building!