HTTP API
Learn how to authenticate and send requests to the EnderDash HTTP API.
About this API
EnderDash generates this authenticated HTTP API from the app's oRPC router.
This API does not use the live browser-to-agent connection. The live connection uses protobuf RPC over WebRTC data channels, with signaling relay fallback.
Authentication
The HTTP API accepts either:
- a signed-in EnderDash session cookie
- a user API key sent as
X-API-Key
It does not accept per-server agent keys or OAuth access tokens. Account OAuth and Game OAuth provide sign-in for other applications. Their access tokens belong to their respective OAuth endpoints.
Agent keys do not authenticate the HTTP API
Agent keys only register an agent to a server record. Use a browser session or user API key for HTTP requests.
OpenAPI documents
- Production schema:
https://app.enderdash.com/openapi.json - Local development schema:
https://app.enderdash.localhost:1355/openapi.json - Generated docs section: OpenAPI
Import the schema into an OpenAPI tool to create requests. You can use tools such as Postman or Insomnia.
Base path and request model
The OpenAPI-compatible API uses the /api/http base path. The dashboard uses a different oRPC endpoint at /api/rpc.
External HTTP clients must use /api/http.
| Operation type | Path shape | Input format |
|---|---|---|
| Query | GET /api/http/<router>/<procedure> | Individual URL query parameters |
| Mutation | POST /api/http/<router>/<procedure> | A JSON request body |
Successful responses contain the result as JSON. The API does not put the result inside an RPC envelope.
Errors use the oRPC HTTP body. This body contains the code, status, and message fields.
Use the generated schema as the source of truth. It defines all parameters, message bodies, and status codes.
What is included
The generated HTTP API includes procedures from these dashboard routers:
activityadminalertsauthchatintegrationsknowledgenotificationsocelotorganizationspwaservers
The admin router manages dashboard-account OAuth clients and requires an EnderDash platform admin.
Game OAuth client procedures belong to organizations and require organization owner or admin access.
The normal EnderDash access rules apply:
- organization membership
- server access
- admin-only procedures
- plan limits
What is not included
- WebRTC signaling and the browser-to-agent transport
- the dashboard's native batched oRPC transport at
/api/rpc - Ocelot streaming chat
Error behavior
| Status | Meaning |
|---|---|
400 | Invalid input |
401 | Missing authentication |
403 | Authenticated but not allowed |
404 | Resource not found |
409 | The resource state or plan limits blocked the request |
429 | Rate limit exceeded |
Make your first request
- Open your user menu in the dashboard and go to account Security.
- In API Keys, create a named user key. Choose an expiry appropriate to the script.
- Copy the secret when it is shown. Store it outside source control.
- Copy the organization slug from its dashboard URL, such as
my-teamin/@my-team. Use the slug, not the display name. - Run the following read-only request from your own shell:
export ENDERDASH_USER_API_KEY='<user-api-key>'
export ENDERDASH_ORGANIZATION_SLUG='<organization-slug>'
curl --fail-with-body \
-H "X-API-Key: $ENDERDASH_USER_API_KEY" \
--get \
--data-urlencode "organizationSlug=$ENDERDASH_ORGANIZATION_SLUG" \
'https://app.enderdash.com/api/http/servers/listServers'Expect a JSON array of accessible server records. An empty array can be a valid response when the organization has no accessible servers. Do not put the key into a URL or screenshot.
The key acts through its user's normal access. It does not grant an organization role or bypass server grants. Revoke a key through the same API Keys area when the script no longer needs it.
The website's generated reference uses an OpenAPI document built from this repository's app router. The running production endpoint can differ while a local change is unpublished. For a client against production, compare its deployed schema before using a new operation.
Diagnose a failed request
401: check the header, expiry, and whether the user key was revoked.403: check the user's membership, role, and server grants.400: compare the query parameters or JSON body with the generated operation.409: inspect the error message for the blocked state or plan limit.429: reduce request frequency and follow the response's retry information when available.
Use --get and --data-urlencode for query parameters. For a mutation, use the documented
POST operation and JSON body. Do not send an oRPC request envelope to /api/http.
Related
Was this page helpful?
Send a quick note if anything is missing or unclear.
Last updated on