Open Exposure Gateway (OEG)¶
The Northbound Interface entry point.
The OEG exposes the platform to App Providers via standardised CAMARA APIs over the Northbound Interface (NBI). It validates Keycloak JWTs, translates each external request into the platform's internal shapes, and either publishes async work to the Service Resource Manager (SRM) on the DataBus (NATS) or calls SRM / Federation Manager over internal HTTP. It does not fulfil deployments or talk to infrastructure itself.
What it does¶
- Terminate CAMARA NBI APIs (Edge Application Management, Quality on Demand, Traffic Influence, Location Retrieval) and the operator federation lifecycle routes under
/platform/v1/federation - Authenticate callers (Keycloak JWT) and enforce role plus CAMARA scope per operation
- Translate CAMARA ↔ SRM schemas; persist operations and resources in PostgreSQL
- Hand off long-running work to SRM via NATS (
command.srm.*/event.srm.*); proxy sync queries and federation setup over HTTP - Deliver CloudEvent callbacks to registered sinks when operations reach a terminal state
APIs¶
Each API is served at the base path its vendored OpenAPI defines. Try them on your install at /docs (on kind: http://localhost:32263/docs). The vendored files and their upstream pins are listed in Interface Contract › Pinned Contract Sources.
| API | Version | Base path |
|---|---|---|
| CAMARA Edge Application Management | 0.1.0-alpha.1 |
/edge-application-management/v0.1alpha1 |
| CAMARA Quality on Demand | 1.1.0 |
/quality-on-demand/v1 |
| CAMARA Traffic Influence | 0.10.0 |
/traffic-influence/v0.10 |
| CAMARA Location Retrieval | 0.5.0 |
/location-retrieval/v0.5 |
Federation lifecycle, operator role (GSMA OPG.04 v6.0, EWBI API 1.4.0, relayed to FM) |
1.4.0 |
/platform/v1/federation |
How OEG is checked against the CAMARA specs¶
Each CAMARA API is pinned to a vendored copy of its OpenAPI file in the OEG repository. Any difference from that file is a conformance failure.
- Conformance suite.
make conformanceruns schemathesis on every operation of each vendored spec (tests/conformance/, one file per API). It sends valid and invalid requests and checks each response against the spec: status code, body schema, content type and headers. OEG runs alone, with SRM, the database and NATS replaced by fakes, so the suite checks the API surface, not the work behind it. - Operations not implemented. The operations that answer
501are left out of the generated runs, and a separate test checks that they still answer501. - References.
tests/unit/test_vendored_spec_refs.pychecks that every$refin the vendored files resolves. - In CI the conformance job runs in every pipeline but does not block a merge.
What a real deployment does end to end is checked by the end-to-end tests. To move to a newer CAMARA version, follow Implementation & Delivery › Update an API Pin or Version; the test setup is in Implementation & Delivery › Testing.
Read in the specs¶
The OEG specification is four documents and three worked flows. Start from the question that matches what you need:
Code and deployment¶
| Repository | open-exposure-gateway (Python 3.12, FastAPI, image tag 2.0.0) |
| Entry point | open_exposure_gateway.main:app (port 8080) |
| Helm | Umbrella chart oop-platform → subchart oeg (Deployment oegcontroller) |
| Dependencies | PostgreSQL (oeg DB), NATS, Keycloak realm oop (audience oeg), SRM, Federation Manager internal API |
| Try it | Swagger UI at /docs — on kind: http://localhost:32263/docs |
| Probes | GET /platform/healthz, GET /platform/readyz (DB + NATS + JWKS) |
Build, local run and startup order are in Implementation & Delivery › Build and Deployment.