Developer Portal
Create apps, configure capabilities and trust, and inspect usage credits
The OpenRTC Developer Portal manages application identities, public API keys, capability manifests, provider registration, budgets, and usage credits.
Every application uses OpenRTC. There is no per-app rollout switch and the portal does not create or update OpenRTC 1.x configuration fields.
Minimum prototype setup
- Create an application.
- Copy its public API key.
- Enable capability spaces or ephemeral rooms.
- Register the browser origins that may request capabilities.
This path creates no product user account or Firebase Auth principal.
Production identity
Register the HTTPS issuer, audience, JWKS, and signing algorithms for assertions produced by your identity backend. OpenRTC validates the assertion and preserves a stable app-scoped principal without taking ownership of your login UX or product authorization.
Managed attestation stores public provider identifiers and policy in the app manifest. Secrets and private keys remain server-side references; they are never stored in the developer-app document or shipped to the SDK.
The portal can register Firebase App IDs, Apple team/bundle/environment/build policy, and Play package/signing/version policy together for a cross-platform app. Apple DeviceCheck is shown separately as a reduced-trust fallback and accepts only a Secret Manager resource name containing the Apple team ID, key ID, and ES256 private key. OpenRTC never accepts that private key in a public identifier field.
Attestation can be disabled, optional on supported platforms, or required. Required is intentionally strict: an unsupported desktop cannot enroll. Evidence is requested only for enrollment, key rotation, recovery, or explicit risk escalation—not for every socket or grant refresh.
Capability manifest
The manifest controls:
- enabled avenues: devices, spaces, rooms, and tickets;
- capability and authenticated access modes;
- allowed origins and registered trust providers;
- relay enabled by default, with an app-wide opt-out;
- durable membership, managed attestation, MoQ, and BLE opt-ins;
- operator-reviewed adaptive-room status (8 peers by default and up to 50 for eligible latest-state sparse rooms; managed fan-out is unavailable in 2.5 and authority remains separately gated);
- payload, velocity, concurrency, technical, per-principal, and app spend ceilings.
An advanced feature is available only when enabled in the manifest and requested by runtime code.
Relay and usage controls
The Security tab exposes five separate controls:
| Portal control | Stored surface | Default and range |
|---|---|---|
| Managed relay fallback | capabilityManifest.features.relay | Enabled for new and migrated apps. |
| Relay-capable admissions per app / hour | capabilityManifest.relay.maxPerHour | 600; integer from 1 to 100000. |
| Relay upload limit | capabilityManifest.relay.uploadMbps | 25 Mbps; decimal from 0.1 to 1000. |
| Relay download limit | capabilityManifest.relay.downloadMbps | 25 Mbps; decimal from 0.1 to 1000. |
| Monthly app credit cap | appMonthlyCreditCapUsd | App-specific USD ceiling; $0.01 to $100000.00. |
The portal writes relay limits through relayMaxPerHour, relayUploadMbps,
and relayDownloadMbps; the returned app model exposes the normalized values
under capabilityManifest.relay.
These are portal control-plane fields, not client SDK options.
The relay admission limit is intentionally conservative. While managed relay is enabled, every gateway grant consumes the app-wide one-hour allowance even if the client eventually establishes a direct route. This prevents stale or modified clients from avoiding the app policy. The independent per-principal gateway safety limit remains 120 admissions per one-hour window.
Managed relay credentials are minted server-side with a one-hour lifetime. If measured relay use exceeds an app-wide bandwidth setting, OpenRTC pauses new credentials and revokes active credentials. Enforcement can follow a short reporting delay, so the settings are safeguards rather than instantaneous Mbps guarantees. An OpenRTC-owned relay enforces the same signed limits at its relay boundary.
Usage
The usage dashboard shows billed credits with simple application, daily, and operation breakdowns, plus a separate relay section. Relay-capable admissions, measured upload/download, and estimated pending bytes remain distinct. A relay-capable admission is not relay traffic, and billed credits update after measured usage settles.
Quickstarts are generated for an API-key prototype, authenticated devices, a collaborative room, a production backend assertion, and managed mobile attestation.
Offline edge trust is local and does not require a portal capability switch. The portal does not receive device private keys, local discovery advertisements, or direct LAN payload. If a future app enables online inventory or signed-bundle synchronization, those hosted operations appear separately in usage credits.