What the ER:LC API Can and Can't Do: A Practical Guide for Server Owners

Research date: 10 November 2026, from the official ER:LC Private Server API documentation (apidocs.erlc.gg) and its published OpenAPI specifications. Part of the ERLC platform comparison series.

If you run an ER:LC private server, you've been sold tools that "connect to the ER:LC API" — staff bots, CADs, dashboards. What that API actually provides defines what any of those tools can really do, and what they're doing on their own. This guide walks through both sides.

Getting access: two keys, two different powers

The server key. Purchased in-game via the "ERLC API" private-server pack, this key goes out in the server-key header of every request. It carries Co-Owner-equivalent authority over your server. Anyone who holds it can run commands as your server's management. Treat it like a password: a platform that leaks it into error messages, logs or support tickets is a platform to avoid.

The application key. A platform serving more than one community (which is what Melonly, Boomerang, Trident and similar bots do) must additionally authenticate globally with an application key in the Authorization header. Without one, a multi-server app gets error code 2005. Applications serving 100+ servers apply through a ticket for a higher-limit tier. IP rotation is forbidden; shared-hosting IPs are explicitly unsupported.

What the API gives you

A single call — GET /v2/server — returns your server's live state. Some fields are always returned (name, owner and co-owners, current/max players, join key, verified-join requirement, team balance); everything else is opt-in via query flags:

• Players, with optional location, callsign, wanted status and permission data
• Staff lists, split into Admins, Mods and Helpers
• Logs: joins, kills, commands, mod calls, emergency calls
• Queue and vehicles

The legacy v1 API splits the same data across separate endpoints and uniquely includes a bans endpoint that v2 does not have — one reason to check which version a vendor actually runs.

Commands go the other way: POST /v2/server/command executes an in-game command (kick, ban, pm, teleport and so on) as "virtual server management". The documented rate example is one command per five seconds.

There is also a webhook mechanism, configured in-game and signed with Ed25519 — but per the current docs it only fires for ;-prefixed messages and emergency calls.

What the API does not give you

This half matters more when you're choosing a platform, because it explains what a vendor must build themselves (and why "integrations" differ so much):

• No identity linkage. There is no "login with ER:LC". The API can tell a platform which Roblox user is in your server; it cannot tell it that Discord user X is Roblox user Y. That mapping comes from the platform's own Roblox verification records — which is why verification quality varies so much between platforms.
• No history. Ban reasons and ban history are not exposed (and v2 has no bans endpoint at all), there are no chat logs, and the documentation provides no archival-retention guarantee — how long live data stays readable is undocumented. Any "historical stats" a platform shows you comes from its own database, collected since you installed it. Your platform's retention policy is effectively your data policy.
• No audit trail. The API doesn't report which commands a third-party platform ran. If your community wants to know who triggered that in-game ban, you depend on the platform's own logging — another reason dashboards with audit logs (like Melonly's and Boomerang's) are worth real weight.
• No server settings mutation, no server discovery. Public servers are out of scope entirely.
• Limited webhooks. Only ;-messages and emergency calls — join/leave and other logs must be polled, which is where rate limits bite.

Rate limits: why they shape every platform's design

Limits are per-key, unpublished ("varies per app"), with documented X-RateLimit headers and a consequence chain the docs make explicit: honour 429's Retry-After or be blocked — error 4001 for invalid-request behaviour, blocking from one minute to hours, and eventually a Cloudflare ban. This is why Melonly's free tier caps API requests at 100/month and why in-game commands have cooldowns on every platform: they're absorbing a real upstream constraint, not being stingy.

Questions to ask any vendor

1. Do you run on API v2 today? (ERM's final act in July 2026 was a v2 migration; Trident's public docs still describe the 2024-era PRC integration. This question separates maintained platforms from stale ones.)
2. Where does my server key live, and can it ever appear in an error message or log?
3. What do you store, for how long, and how do I export it?
4. How do you handle rate-limit blocks — fail open, or fail closed?

For how the major platforms answer in practice, see the ecosystem comparison. For what happens when a platform's answers stop mattering because it shut down, see the ERM/Ducky post-mortem.