Integrations
Setting Up and Using RaidHelper
Connect RaidHelper events to GearCheck readiness, build mappings, signed-up members, and flex coverage.
Who uses it
Raid leads, managers, event coordinators
Where it lives
Dashboard > RaidHelper and /raidhelper commands
Goal
Staff can check whether signed-up members are ready for what they selected and see alternate coverage options.
Before You Start
- Subscriber or higher access where RaidHelper is gated.
- A RaidHelper server API key, not a user API key.
- GearCheck builds that map to the event roles or labels.
Steps
Use the server API key
RaidHelper has user and server API keys. GearCheck needs the server-wide key from the non-user settings API key command so it can list server events.
Configure watched channels if needed
Auto-detect can work, but watched channels help GearCheck find event embeds reliably. If list lookup fails, paste the event ID or message link directly.
Map event labels to GearCheck builds
Role-specific events are easiest to match. Generic events may need saved mappings or staff interpretation. Keep mappings human-readable so raid leads can trust the report.
Run readiness
Generate the report to see each signup, selected role/build, latest GearCheck result, readiness bucket, and verification link.
Use flex coverage
When a role or build has a gap, check whether signed-up members have other verified builds that could cover it. GearCheck suggests possibilities; staff still make the roster call.
Launch Checklist
- Events list or direct event lookup succeeds.
- Mappings resolve to expected GearCheck builds.
- Generic events are labeled clearly instead of pretending to be role-specific.
- Flex candidates include score, recency, and verification context where available.
Common Pitfalls
- Using a user API key instead of a server API key.
- Assuming RaidHelper signups prove gear readiness without GearCheck data.
- Letting GearCheck auto-decide swaps instead of treating flex as staff guidance.