Skip to content
Elimi Docs

Orchestrator overview

Orchestrator

Section titled “Orchestrator”

Audience: all
Status: specced
Owns: backend / product
Depends on: Backend stack ADR, System architecture, Domain overview, Ecosystem map, Architecture handover

Shared services for CAP, LMS, and WorkMasters. One account on Orchestrator is the SSO surface: credentials created for CAP can sign in to LMS (and other intents) without a separate identity store.

Owned capabilities

Section titled “Owned capabilities”
Capability v1 scope
Auth Register (email/password or Google), OTP verify, login, forgot/reset, change-password, delete-account (deactivate + user.deleted); JWT + JWKS; signup intents[] drives provisioning
Notifications Channels: email, in-app, sms (off by default); inbox REST + GET/PUT /notifications/preferences; notification.requested / in-process dispatch skip disabled channels except auth-critical templates. Distinct from chat
Conversations Two-way threads (direct / group / broadcast). Client REST send/list/poll. Optional in-process notify (channel allow-list; email/SMS off by default). No CAP hop and no gRPC on Send
Identity verification NIN first via gRPC VerifyIdentity; provider-agnostic port; CAP owns client-facing entry
Payment Processing only — gRPC initiate; Paystack webhook + verify REST; never owns price — Payment architecture
Storage Signed upload / resolve / delete REST; sensitive assets resolve-on-access

Competency stays in CAP. Infra and messaging: System architecture.

Role lenses

Section titled “Role lenses”
  • API — validated OpenAPI (openapi/orchestrator.yaml, 35 operations)
  • Backend — modules, outbox, console shell
  • Data model — Prisma outline

How apps consume Orchestrator

Section titled “How apps consume Orchestrator”
flowchart TB
  subgraph orch [Orchestrator]
    Auth[Auth]
    Notify[Notifications]
    Chat[Conversations]
    ID[Identity]
    Pay[Payment]
    Store[Storage]
    Auth -->|OTP / mail| Notify
    Chat -->|optional ping| Notify
  end
  CAP[CAP]
  LMS[LMS]
  WM[WorkMasters]
  Auth -->|JWT + user.created| CAP
  Auth -->|user.deleted| CAP
  Auth -->|JWT + intents| LMS
  Auth -->|JWT| WM
  CAP -.->|JWKS verify locally| Auth
  CAP <-->|gRPC VerifyIdentity| ID
  CAP -->|gRPC InitiatePayment| Pay
  Pay -->|payment.completed| CAP
  CAP <-->|signed URLs| Store
  • Orchestrator issues JWT; other apps validate via JWKS — no per-request auth round-trip.
  • Register with intents: ["cap","lms"] → emit provisioning (user.created); CAP creates cap_users + onboarding record.
  • Auth does not embed SMTP; it uses Notifications (crash-safe path via outbox).
  • Payment: client hits CAP pay endpoint; CAP prices and calls OL over gRPC; provider webhooks hit OL only.
  • Gateway: /v1/ol/… — staging www.staging-api.elimi-ecosystem.e-limi.africa, production api.elimi-ecosystem.e-limi.africa.

Maturity

Section titled “Maturity”

Specced — OpenAPI and Prisma schemas are design-complete and validated; @yourorg/common / @yourorg/proto scaffolds exist. Domain implementation (Express services, migrations) is still ahead. See Maturity.

See also

Section titled “See also”