Authentication
The YipYap API authenticates via API keys on the Authorization header. Session cookies are accepted for first-party console access but are not part of the public contract.
Getting an API key
Section titled “Getting an API key”See Integrations → API Keys for the setup guide. Keys are created in the console under Settings → API Keys and are shown exactly once at creation time.
Using an API key
Section titled “Using an API key”Include the key as a Bearer token on every request:
curl https://console.yipyap.run/api/v1/monitors \ -H "Authorization: Bearer yy_live_AbCdEfGhIjK..."Keys are prefixed so you can identify them at a glance:
| Prefix | Meaning |
|---|---|
yy_live_ | Production SaaS key. |
yy_test_ | Sandbox/testing SaaS key. |
yy_foss_ | Key for a self-hosted FOSS deployment. |
Scopes
Section titled “Scopes”Each key is issued with a set of scopes; the server rejects requests whose path requires a scope the key does not hold. Follow least-privilege: a Prometheus-to-YipYap bridge only needs events, not monitors.
| Scope | Grants |
|---|---|
monitors | Read/write monitors, monitor groups, custom states. |
alerts | Read alerts; acknowledge and resolve. |
escalation_policies | Read/write escalation policies and steps. |
notification_channels | Read/write notification channels. |
maintenance_windows | Read/write maintenance windows. |
status_pages | Read/write status pages. |
services | Read/write the service catalog. |
incidents | Read/write incidents and incident updates. |
schedules | Read/write on-call schedules. |
teams | Read/write teams. |
events | POST to the inbound Events API (/api/v1/events). |
heartbeat | POST to the heartbeat API. |
cloudevents | POST to the CloudEvents ingest endpoint. |
admin | Org-level admin operations (API keys, settings, billing). |
Scopes are additive. A request that requires two scopes (e.g. reading a monitor and dispatching a test notification) needs both on the key.
Session cookies
Section titled “Session cookies”Logged-in console users authenticate via a JWT session cookie set by POST /api/v1/auth/login. The console UI uses this; the public API reference assumes you are using an API key. Endpoints under /api/v1/auth/**, /api/v1/billing/**, and any route that changes account-level settings are only reachable by a logged-in session, not by an API key.
Service-to-service authentication
Section titled “Service-to-service authentication”For machine-to-machine integrations behind OIDC (e.g. Knative Eventing sources posting CloudEvents to YipYap), see Knative Eventing → Authentication. The CloudEvents ingest endpoint validates OIDC-issued JWTs directly; API keys are accepted as a fallback only for simple clients.
Impersonation
Section titled “Impersonation”There is no public impersonation API. Internal staff impersonation lives under /api/internal/v1/impersonate/{orgID} and is gated to YipYap operators with hardware-key MFA; it is never callable by customer keys.