External Applications

The only difference between the Bundled Applications and External SaaS Applications is that the external applications reside outside the Poly CloudSaaS Google Cloud Platform is its physcal location. Every subscriber can add any SaaS application to his Passthrough Applicatons and get the same benefits.

Capture Once, Orchestrate Everywhere

How PolySaaS turns any external SaaS application into a reusable data source

One of the foundational principles of PolySaaS is that external SaaS applications are resources that can be exploited without modifying them in any way. We do not require the vendor to change their product, expose special endpoints, or grant us privileged access beyond what a normal user or API client would have.

Instead, we use a spectrum of capture mechanisms — ranging from a relatively simple proxy, through hybrid webhook + API approaches, all the way to full API polling — to make the application’s data consumable. The goal is always the same: capture as much useful data as possible, publish it once into a message bus (Pub/Sub or RabbitMQ), and let any interested consumer take only what it needs.

The Role of PolySniffer

Before we can capture anything intelligently, we need to understand the target application. That is the job of PolySniffer.

PolySniffer examines the external SaaS application and produces a detailed map of its structure, endpoints, data shapes, authentication patterns, and interaction flows. Our AI then uses that map to generate a purpose-built handler specific to that application. The handler knows how to talk to the app — whether through passthrough traffic, webhooks, or direct API calls — and how to extract the maximum available data with the least friction.

Once the handler exists, user navigation and system activity become seamless capture opportunities. Data flows out of the external application and into our message bus without the end user ever noticing.

The Spectrum of Capture Mechanisms

Not every external SaaS application can be handled the same way. Our architecture therefore supports three primary modes:

  1. Proxy / Event-Driven Capture
    When traffic can flow through our platform (passthrough), we observe the live HTTP requests and responses in real time. This is the richest and most immediate form of capture.
  2. Hybrid Webhook + API
    When the vendor offers reliable webhooks, we combine event notifications with targeted API calls to fill in the gaps.
  3. Full API Capture
    When neither proxying nor webhooks are available or sufficient, the handler actively retrieves data through the application’s public or authenticated APIs on a schedule or on demand.

In every case the outcome is identical: structured events are published to a topic on Pub/Sub or RabbitMQ. Downstream consumers subscribe only to the topics (or message types) they care about and simply ignore the rest.

The Two-Layer Philosophy: Capture vs. Consume

We maintain a strict separation between capturing data and acting on it.

  • Layer 1 – Capture
    The handler’s only job is to obtain the data (via proxy, webhook, or API) and publish a clean, standardized event to the message bus. It does not transform business logic, apply rules, or make decisions.
  • Layer 2 – Consume
    Completely independent services monitor the message bus. They pick up the events they are interested in, transform or enrich the payload as needed, and perform whatever orchestration, storage, AI processing, or workflow actions are required.

This separation is the key to scalability. We never write one-off extraction code for “Odoo contacts” versus “Salesforce opportunities” versus “Mattermost channels.” New applications require a new handler and new Instruction configuration — not a new codebase.

What Gets Published

Every captured event follows a consistent structure so that any consumer can process it the same way, regardless of the original application:

{
  "capture": "get_response | post_request | api_pull | webhook",
  "topic": "RES.odoo.contacts.pso13",
  "action_path": "/odoo/contacts",
  "method": "GET",
  "direction": "RES",
  "source": "passthrough | webhook | api",
  "response_meta": {
    "status_code": 200,
    "content_type": "application/json"
  },
  "data": { ... },
  "username": "pso13",
  "handler_id": "odoo-v1",
  "eventKey": "odoo.contacts"
}

Topic naming remains predictable so consumers can bind with precision — by direction, by application, by tenant, or any combination.

Why This Architecture Wins

  • App-agnostic — We work with whatever interface the external application actually offers (HTML, JSON APIs, webhooks, or a combination).
  • Zero modification of the external app — We never require the vendor to change anything.
  • Capture once, use many times — A single rich stream of events can feed AI orchestration, analytics, compliance, notifications, and customer-specific logic simultaneously.
  • Future-proof — Moving from local RabbitMQ to cloud Pub/Sub (or any other message bus) requires no change to the capture model or the Instruction layer.
  • Configuration over code — Adding support for a new SaaS application is primarily a matter of running PolySniffer, generating a handler, and defining Instructions — not writing new extraction logic.

By treating every external SaaS application as a data resource that can be observed and streamed, PolySaaS turns the usual integration mess into a clean, reusable, event-driven fabric. The data is captured once. Everything downstream simply decides what it wants to do with it.