Service Overview

From its README: “a high-performance FastAPI microservice responsible for managing and serving sales opportunities. It enforces strict multi-tenant isolation and complex visibility rules based on the RIO Hierarchy and RBAC models.”

In practice it is a read API. Every one of its 15 routes is a GET. Opportunity records themselves are written by the Data Ingestion Service from the CRM, not by this service.

Its real job: deciding who can see what

The interesting logic here is visibility. A request is allowed to see an opportunity if any of four conditions holds:

1. Ownership — you own the deal.
2. Deal team membership — you are on the deal team.
3. Hierarchy subtree — you have can_view_subtree and the owner sits under you, matched against level_1_id … level_10_id.
4. Regional data — you have can_view_region_data and the deal’s territory matches yours.

These are combined into one SQL OR block so visibility is resolved in the database rather than by filtering in the application.

It listens to nothing

No EventBridge rules, SQS queues or event source mappings. The only non-HTTP trigger is a nightly cron: ${DeployPrefix}-opportunity-history-daily-sync, cron(0 0 * * ? *) UTC (infrastructure/template.yaml:297-309).

Data stores

Written: ClickHouse fact_opportunity_history only — a daily snapshot written by the history-sync Lambda.

Read only: Postgres person, tenant_role, tenant, opportunity, deal_team; ClickHouse dim_opportunity, dim_person_flat, dim_account, fact_opportunity_product, dim_product, dim_territory, fact_quote, fact_bpf_history and related detail tables; the DynamoDB PII vault.

There is no OpenAPI spec file in this repository, so no interactive explorer is attached here.

Inbound and Outbound Message Flow