Grant (positive delta) or revoke (negative delta) coins.
A revoke clamps at zero. A negative balance silently blocks every future purchase with no explanation the player can act on, and support would have to undo it by hand.
Optionalreason?: stringSubtract what a range of flush batches awarded, clamped at zero.
This is not an undo — deltas are not invertible once superseded (earn 500, buy a 500-coin rod, undo, and the balance goes negative while they keep the rod). It reads what those batches actually applied and reverses that much.
Dry-run unless apply is true. Each subtraction is idempotent per player per range, so a
retried apply cannot double-charge.
Optionalapply?: booleanOptionalreason?: stringDisable a content row. Nothing is hard-deleted — player rows store content ids (claimed sets, caught species, owned items), so removing a row would orphan them.
Abuse review queue.
A queue of things for a HUMAN to look at, never a list of confirmed cheats. Detection runs
against an economy with no live data, so its false positives are disproportionately legitimate
heavy players — the most engaged users in the feature. Nothing here bans, and there is
deliberately no bulk action: confirmed abuse is actioned through resetTarget,
adjustPlayerCoins or setKill, each of which writes an audit row.
Defaults to PENDING flags, ordered most-severe-first.
OptionalguildOptionalkind?: FishingAbuseKindOptionallimit?: numberOptionaloffset?: numberOptionalseverity?: FishingAbuseSeverityOptionalstatus?: FishingAbuseStatusOptionaluserWho ran what, with before → after. Distinct from the coin ledger, which is where coins came from.
Optionallimit?: numberThe editable content tables, plus the currently effective content version.
Every dial with its current value and its permitted bounds.
Rollout state, active kill switches, pending flush backlog and Redis memory.
Global progression, plus per-guild wallet/inventory/ledger when guildId is supplied.
OptionalguildOptionallimit?: numberReset a player's server stats, their global progression, a guild's dock, or a guild's economy.
claimedSets and claimedMilestones are preserved unless alsoClearClaims is set. They
record what a player was already paid for — clearing them makes every milestone and collection
pay out a second time as the counters climb back, so "please reset me" becomes a faucet. Setting
the flag is audited as its own action. A dock reset likewise preserves prestige.
OptionalalsoOptionalguildOptionalreason?: stringOptionaluserSet a dial, or pass value: null to reset it to its seeded default.
Out-of-range values are rejected with a 400, not clamped — an operator who typed 500 should learn it did not take rather than quietly getting 3.
Optionalreason?: stringThrow or clear a kill switch.
scope is either a subsystem (cast, sell, boss, …) or a single target (guild:<id> /
user:<id>). A kill stops INGESTION only — the flush keeps draining, so throwing a switch mid
incident does not destroy a window of every active player's progress.
Optionalreason?: stringAdd or remove guilds from the beta allowlist. This is what starts a beta cohort.
Set the percentage dial.
0 is the fleet-wide kill switch — the fastest way to stop fishing everywhere without a deploy. It stops ingestion only; the flush keeps draining so nobody's unflushed progress is lost.
Mark a flag reviewed, or reopen one.
Pass reviewed: false to reopen — a reviewer who dismisses the wrong row otherwise has no way
back, because the queue's day-grained dedupe key stops the same condition re-raising it.
Reviewing is also what makes retention work: reviewed flags age out after 30 days, unreviewed ones after 90.
Optionalreason?: stringOptionalreviewed?: booleanCreate or update one content row (upsert — one verb, not two).
For dateDerived tables the change does not apply today: effectiveFrom in the response is
the next 00:00 UTC. Daily demand, the shop rotation and the quest board are a date-seeded shuffle
over the content list, so editing it mid-day would reshuffle a day players already acted on.
Optionalreason?: string
Dev-only backend for the Fishing minigame admin dashboard.
Every method here requires a developer account — the routes check the caller against the developer list and return 403 otherwise, so these are not merely "admin" in the guild-owner sense.
Endpoints live under
/admin/minigames/fishing/*. Theminigamessegment is deliberate: Fishing is the first minigame, not the only one, so a second game slots in beside it rather than replacing it.