--- title: 'ER:LC Integration' slug: 'erlc' category: 'Servers' order: 10 description: 'Connect CADLY to your ER:LC private server for player data, commands, and automation.' --- # 1 - Introduction ER:LC integration connects CADLY to your in-game private server using the ER:LC API key. CADLY reads player lists, queues, server info, vehicles, mod calls, command logs, kill logs, and related server state. This integration powers the CAD panel, dispatch, action engine, restrictions, reminders, sessions, deployments, and live ER:LC commands. For most communities, ER:LC integration is the difference between CADLY being a Discord management panel and CADLY being a live operations system. Once connected, CADLY can see who is in-game, which team they are on, what commands are being used, and whether configured restrictions are being violated. Treat the ER:LC API key like a sensitive credential. Anyone who can configure or share it can affect live server behavior through CADLY features. Give ER:LC settings access only to trusted administrators. ## 1.1 - Table of Contents | Section | What it covers | | ----------------------------------------------------- | ------------------------------------------- | | [Setup](#2---setup-and-data) | ER:LC keys, live data, and refresh behavior | | [Commands](#3---in-game-commands) | Slash commands and allowed ER:LC commands | | [Settings](#4---settings--configuration) | ER:LC settings reference | | [Troubleshooting](#5---troubleshooting-common-issues) | Common connection and rate-limit issues | ## 1.2 - Links to Related Documents - [Action Engine](/docs/action-engine) - [Dispatch & CAD](/docs/dispatch) - [Server Settings](/docs/server-settings) # 2 - Setup and Data Add your ER:LC API key in Settings, ER:LC, API Keys. Keys are managed by server slot, so dual-server communities can configure Server A and Server B separately. CADLY encrypts saved keys and only shows safe key details in the panel. If a Department Server receives a shared key from a Host Server, its ER:LC settings can be locked by the shared key state. Before adding the key, confirm it belongs to the correct ER:LC private server. If you run multiple servers, label internally which key maps to Server A and which maps to Server B so staff do not accidentally send commands to the wrong place. After saving a key, open the ER:LC panel and check that player data appears. The first refresh can take a short time because CADLY validates the key and starts live data updates. ```cadly-mock type: status title: ER:LC server connection meta: Settings > ER:LC > Server A status: Connected items: - Key Status | Valid - Player Polling | Fast mode - Command Queue | Ready - Shared Departments | 3 linked ``` ## 2.1 - Refresh Intervals CADLY refreshes active server slots more often than idle slots. This keeps live workflows responsive without wasting ER:LC request capacity. | Mode | Interval | When used | | ---- | ---------------: | --------------------------------------------------------------------- | | Fast | 40 to 45 seconds | CAD, dispatch, sessions, or another consumer recently requested data. | | Slow | 400 seconds | No recent demand for that guild and server slot. | ## 2.2 - Request Routing and Rate Limits CADLY manages ER:LC request traffic and watches for rate limits. If ER:LC starts slowing or rejecting requests, CADLY reduces pressure and rebalances traffic across active keys. Command posting is paced per ER:LC key so shared keys do not receive too many commands at once. User commands also require CADLY command-tier permissions. This means a command can be accepted by CADLY but still wait briefly in the queue. That delay is normal under load and helps prevent a key from being rate limited. If many automations and staff are sending commands at once, simplify automations or raise cooldowns. # 3 - In-Game Commands Use **/erlc command** with `command`, `server`, and optional `args`. Use **/erlc info** for a server overview, **/erlc players** for the player list, and **/erlc membercheck** to compare in-game players with Discord members. The command autocomplete uses CADLY's command policy, so staff only see commands CADLY knows how to handle. The command text is normalized before sending, so staff can use names such as `kick` instead of typing the leading colon. Commands are permission-tiered by server slot. A staff member with moderator commands on Server A does not automatically have administrator commands or Server B access. ```cadly-mock type: command title: /erlc command meta: In-game command bridge status: Permission checked items: - command | kick - args | RiversideUnit_42 Fail roleplay - server | Server A ``` ## 3.1 - Command Policy | Tier | Commands | | ------------- | ------------------------------------------------------------------ | | Moderator | `:h`, `:m`, `:pm`, `:kick`, `:load`, `:wanted`, `:jail`, `:unjail` | | Administrator | `:aop`, `:tban`, `:ban`, `:unban`, `:mod` | | Owner | `:admin`, `:unadmin`, `:setmaxplayers`, `:shutdown` | Aliases include `hint` for `h`, `message` for `m`, and `tempban` for `tban`. # 4 - Settings / Configuration ## 4.1 - Core ER:LC Settings ### Enable ER:LC Turns ER:LC data panels and integrations on. **Default:** off | **Requires:** none ### ER:LC Keys Saves encrypted ER:LC keys for Server A and optional Server B. **Default:** none | **Requires:** none ### Feedback Channel Channel for ER:LC notifications such as failed unbans or queue errors. **Default:** none | **Requires:** none Set this to a private admin channel. It helps leadership notice key errors, command queue problems, or failed background operations before staff report broken features. ### Mono Server Mode When on, only Server A is active. When off, Server A and Server B can each have keys, roles, dispatch sync, and permissions. Find this toggle at the bottom of **Settings > General**. **Default:** on | **Requires:** none ## 4.2 - Advanced ER:LC Features ### Bloxlink Integration Saves a Bloxlink key and can automatically match Roblox users to Discord users. The key is only required when Verification is disabled. With Verification on, CADLY resolves players through the accounts they verified with, and a Bloxlink key just extends that to members who linked with Bloxlink but never verified. With Verification off and no key, CADLY cannot match in-game players to Discord members, so permission sync and every role-based restriction skips them. **Default:** not configured, auto-convert on | **Requires:** Verification enabled, or a Bloxlink key ### Discord Reminder PMs Periodically PMs players who are in the game but not in your Discord, asking them to join. CADLY resolves every player it sees, keeps only those it can confirm are not a member of your Discord, and sends one grouped in-game message per batch: `:pm user1,user2,... {your message}`, up to 10 players per message. In-game staff are never messaged, and any player whose account cannot be checked at that moment is skipped rather than messaged by mistake. Configured per Server A / Server B. Sweeps every 10-30 minutes; PRO servers can go down to 5. Because it rides the normal ER:LC poll, the real gap can be slightly longer than the slider when a server is polling slowly. **Default:** off | **Requires:** Verification enabled, or a Bloxlink key ### Welcome Message Sends an in-game message to every player when they join. **Default:** off | **Requires:** none ### Troll Account Prevention Automatically bans usernames that start with dangerous broadcast-like names such as `all` or `others`. **Default:** off | **Requires:** none ### Log Webhook Processing Processes in-game `:log` commands through a Discord webhook and can create moderation logs. **Default:** off | **Requires:** none ### Off-Duty Detection Detects restricted commands from off-duty roles and punishes, warns, or pings HR. **Default:** off | **Requires:** none Use this carefully. Start with HR ping or warning before enabling kick-style punishment, and make sure off-duty roles are assigned consistently. ## 4.3 - Authorize Remote Commands ER:LC requires the server owner to authorize CADLY before it can send remote commands such as kick, ban, teleport, and automated messages. GET data can continue working even when remote commands are not authorized. ### Completing authorization 1. Open **Settings > ER:LC > API Keys** and select **Authorize CADLY** for the server slot. 2. Open the ER:LC authorization page and approve CADLY for that server. 3. Return to CADLY and select **I've authorized, enable POST commands**. CADLY enables commands immediately after confirmation. ER:LC verifies the authorization when the next real command is sent. If ER:LC returns code `4000`, CADLY disables remote commands again and shows the authorization action. GET data remains enabled. ### What happens if you skip this **New ER:LC keys** have POST commands disabled by default until this step is completed. Kick, ban, teleport, and other remote commands will not send until you authorize and confirm. If authorization is later revoked in ER:LC, CADLY turns POST commands off automatically. Authorizing CADLY again restores them. # 5 - Troubleshooting Common Issues ## 5.1 - No ER:LC Data Appears Confirm ER:LC is enabled, the ER:LC key is valid, and the selected server slot has a key. ## 5.2 - Commands Fail Check your CADLY ER:LC command permission tier for the selected server slot. Also make sure command arguments fit the single-line and length limits. If POST commands recently stopped working, repeat the [authorization step](#43---authorize-remote-commands). ## 5.3 - Data Is Delayed The server may be in slow mode until a panel or feature touches it. Open CAD or refresh ER:LC data to mark the slot active. # 6 - Getting Support and Resources If you need help, several resources are available: - [CADLY Documentation](/docs): Detailed reference for all features. - [CADLY Support Server](https://discord.gg/cadly): Join for **fast help** from the team. - [CADLY Email Support](mailto:admin@cadly.me): Reach out **via email** for direct support.