API Reference
The YipYap API lets you manage monitors, alerts, on-call schedules, notification channels, and status pages programmatically. Every feature in the console is reachable via the API; the console itself is just one client.
Base URL
Section titled “Base URL”https://console.yipyap.run/api/v1All endpoints documented in this reference are rooted at /api/v1. Self-hosted deployments replace the host with their own.
Content types
Section titled “Content types”Requests and responses are JSON unless noted (status-page public endpoints serve HTML; the inbound CloudEvents ingest endpoint accepts application/cloudevents+json and application/cloudevents-batch+json).
Send Content-Type: application/json on every POST, PUT, and PATCH. Omit the body on GET and DELETE.
Versioning
Section titled “Versioning”The /api/v1 prefix is the stable public API. Breaking changes ship under /api/v2 with a documented deprecation window for v1. The /api/internal/v1 namespace is reserved for staff operations and is not part of the public contract.
Request IDs
Section titled “Request IDs”Every response includes an X-Request-ID header. Quote this ID when opening a support ticket; it lets us correlate your request against our logs.
There is no first-party SDK at this time. The API is designed to be easy to call directly with curl, requests, fetch, or any HTTP client. A Go client lives inside the YipYap repo for internal use; it is not published as a library.
What’s next
Section titled “What’s next”- Authentication: how to create and use API keys.
- Conventions: pagination, filtering, timestamps, IDs.
- Errors: the error body shape and common codes.
- Rate limits: per-tier caps and headers.
Then head to the per-resource reference pages: Monitors, Alerts, Escalation Policies, and so on.