Oral Pro
AD
Admin Useradmin@oralpro.demo
Filter Data
Last 30 Days
3

System Architecture & Data Flows

An in-depth breakdown of how Oral Pro ingests raw API endpoints and outputs secure, AI-driven operational insights.

Interactive Data Pipeline

Click on any layer below to inspect the engineering logic.

Primary Reporting Base: EUR (€) Data Integrity: Guaranteed
Ingestion Layer

1. Data Extraction & Webhooks

Captures live business events from disparate external servers as they happen.

Technical Specifications:

Real-time Webhooks: Stripe payment success and Close CRM lead status changes are pushed instantly via HTTPS webhooks.
Micro-Batch Polling: Wise, Revolut, and Mercury balances are queried every 5 minutes using secure API cron triggers.
Meta Ads Extraction: Meta Ads account expenditure data is polled in 5-minute intervals to capture real-time ad spend changes.
Concept Analogy:

"Like postmen constantly delivering letters from 6 different cities directly to our sorting office."

Click other stages to explore their specifics.

Key Architectural Questions (For Presentation Review)

Why pull Close CRM data into a PostgreSQL cache?

We copy CRM data into local PostgreSQL tables to eliminate API rate limits (HTTP 429) and network latency. Direct API calls would cause 10-second page lags. In contrast, local Postgres queries load in under 10ms. Furthermore, you cannot SQL JOIN Close CRM data with Stripe revenue inside Close CRM's external servers. Storing data locally is mandatory for cross-platform analytics.

How are multi-currency conversions normalized?

Stripe receives payments in USD, Wise captures EUR transactions, and Revolut holds GBP. The ingestion pipeline solves this by aligning every transaction timestamp with hourly European Central Bank (ECB) exchange rates. Data is written to the analytical database in both local currencies and converted Euros (€) to prevent rounding errors or FX valuation drift.

What is Entity Resolution & Customer Mapping?

A single company customer might be registered under customer ID `cus_821` inside Stripe and lead ID `lead_404` inside Close CRM. To prevent double-counting or disconnected metrics, our dbt core pipeline resolves duplicates by matching verified primary email addresses, mapping all records to a single unified customer profile.

Why should we never let an AI do financial math?

LLMs (AI engines) are statistical text predictors and are notoriously bad at running complex financial math natively, leading to hallucinations. In our architecture, the **dbt Transformation layer calculates all metrics deterministically** using rigid SQL queries. We then feed these 100% correct pre-calculated numbers into the LLM context, instructing the AI only to explain patterns and suggest recommendations.