A single, coherent backend layer that every EHF service talks to. It holds the foundation together — from member identities and project data to real-time emergency dispatch.
What it is
Infrastructure, not a product. The EHF API is the invisible layer beneath every user-facing service the foundation operates. It was not designed to be accessed directly by end users — it is the contract between what the community does and how that data is stored, validated, and surfaced.
It serves a single foundational purpose: make every part of the EHF ecosystem speak the same language. Member profiles, in-game resources, scheduled events, quest progress, and emergency operations all live here, consistently modelled and reliably retrieved.
Discord as the identity layer. Every entity in the system is anchored to a Discord identity. Roles, permissions, and access boundaries are derived from the community's Discord server in real time — meaning the API always reflects who someone is within the foundation, not just who they registered as.
What it serves
Identity & membership
Unified member profiles bridging Discord accounts, Star Citizen characters, roles, and reputation — the source of truth for who belongs to the foundation.
Projects & coordination
Operational projects with members, rankings, shared item banks, and contribution tracking across every active operation.
Session & inventory management
Structured logging of in-game sessions — what was collected, by whom, where, and at what value — feeding both the workspace and the economy.
Quest & reward engine
The mechanics behind guild quests: acceptance, step completion, point allocation, and the reward shop that converts effort into perks.
Calendar & events
Shared event scheduling across projects, with registration, attendee tracking, and state management from creation to closure.
Emergency dispatch
Real-time coordination layer for the EHF Emergency service — matching distress requests to available responders across the Star Citizen universe.
Design intent
One API, many surfaces. Rather than building independent backends for each service — the emergency platform, the workspace, the analytics tooling — the foundation chose to centralise. A single API means a single source of truth: a change to a member's profile, a completed quest step, or a closed emergency intervention is immediately reflected everywhere.
This architecture trades some isolation for coherence. It is a deliberate choice suited to a community where the same person may be requesting emergency assistance, leading a project, and completing quests within the same session.
What it is not
Not a public API. The EHF API is internal infrastructure. It has no public documentation, no open registration, and no external consumption. Access is restricted to EHF services running against authenticated sessions.
It is listed here as an experiment because it represents a meaningful engineering effort — the kind of invisible work that makes every visible product possible. A reminder that the interesting problems are often the ones nobody sees.