Internal endpoints
The Eternaltwin backend serves a few routes outside /api/v1. They exist for
the official website, for the OAuth browser flow, or for telemetry.
They are not part of the public API. They have no stability guarantee, they are not versioned, and they may change or disappear without notice. Nothing here should be called by an application; the supported surface is /api/v1.
/oauth — the OAuth browser flow
Defined in crates/rest/src/bff/oauth.rs, discord.rs and gitlab.rs.
| Method | Path | Purpose |
|---|---|---|
GET | /oauth/authorize | Start an authorization. Redirects a guest to /login, a user who has not answered yet to /consent, a user who has not accepted the terms to /tos-accept, and otherwise to the client callback with a code. |
POST | /oauth/token | Exchange an authorization code for an access token (RFC 6749). |
GET | /oauth/callback | Callback of the Twinoid authorization flow. |
GET | /oauth/callback/discord | Callback of the Discord account-linking flow. |
GET | /oauth/callback/gitlab | Callback of the GitLab account-linking flow. |
/oauth/authorize and /oauth/token are the two endpoints an application
actually uses; they are documented for application authors in
Eternaltwin for OAuth. The data behind the consent
screen is served by /api/v1/oauth_consent.
/actions — the website backend-for-frontend
Defined in crates/rest/src/bff/actions/. These endpoints back forms of the
official website and answer in whatever shape those pages need.
| Method | Path | Purpose |
|---|---|---|
POST | /actions/register | Registration form. |
POST | /actions/login/discord | Sign in through Discord. |
POST | /actions/login/gitlab | Sign in through GitLab. |
POST | /actions/link/dinoparc | Link a Dinoparc account. |
POST | /actions/link/discord | Link a Discord account. |
POST | /actions/link/gitlab | Link a GitLab account. |
POST | /actions/link/hammerfest | Link a Hammerfest account. |
An application that needs the same effects should use /api/v1/users and /api/v1/auth/self instead.
/v1/logs and /v1/traces — OpenTelemetry collectors
Defined in crates/rest/src/logs.rs and crates/rest/src/traces.rs. Both
accept an OTLP/HTTP protobuf body (ExportLogsServiceRequest,
ExportTraceServiceRequest) and answer with the matching protobuf response.
They are enabled only when an OpenTelemetry backend is configured. The caller
must authenticate as an OAuth client (HTTP Basic with the client key and
secret) and that client must have a human-readable key such as
dinorpg@clients; the application and channel of that key are matched against
the service.name and deployment.environment attributes of every submitted
resource. Anything else is refused with 403 or 422.
Note the path: these live at /v1/logs and /v1/traces, not under /api,
because that is where an OTLP exporter expects to find them.
Test-only routes
crates/rest/src/test.rs is compiled under #[cfg(test)] only. It builds
in-memory systems for the crate's own tests and serves no route on a running
server.