Skript

On by default in settings.yml:

hooks:
  skript: true

Ignored when Skript is not present, so there is no harm in leaving it on.

Registration is logged on startup: Registered Skript syntax. If you do not see that line, Skript loaded after BlazeBans or is not enabled.

if blazebans banned player:
    send "You are banned."

if blazebans muted player:
    send "You are muted."

if blazebans warned player:
    send "You have an active warning."

Each accepts an offline player or a string name:

if blazebans banned "Steve":
    broadcast "Steve is banned."

set {_reason} to blazebans ban reason of player
set {_reason} to blazebans mute reason of player
set {_reason} to blazebans ban reason of "Steve"

Returns the stored reason of the player's active ban or mute.

Create a punishment:

blazebans ban player because "Cheating"
blazebans mute player because "Spam"
blazebans warn player because "Excessive caps"
blazebans ban "Steve" because "Cheating"

Revoke one:

blazebans unban player because "Appeal accepted"
blazebans unmute player
blazebans unwarn "Steve" because "Mistake"

The reason is optional on revocations. Without one, punishments.default-revoke-reason is used.

Conditions and expressions read from a one-second cache rather than querying the database each time.

That matters for how they behave: the first check on a player kicks off an asynchronous lookup and returns false immediately, then the real answer is cached and returned on subsequent checks. A script that checks once on join and acts on the result may act on the pre-lookup value.

Where the answer has to be right, check on a short delay:

on join:
    wait 1 second
    if blazebans muted player:
        send "You are still muted."

They are ordinary records. They appear in /history, they enforce normally, they broadcast, and they post to Discord.

The staff name recorded is the script's context, which usually reads as console. If attribution matters, run the console command with --punisher instead:

make console execute command "ban %player% 7d Cheating --punisher %{_staff}%"

The registered syntax covers the common cases. Anything beyond it, run the command from console:

make console execute command "ban %player% 30d Cheating --proof https://example.com/clip"
make console execute command "punish %player% Spam"
make console execute command "blazebans lockdown enable confirm"

Console bypasses permission checks, staff hierarchy, group exemptions, and scope. exempt.players is still respected.

That is more flexible than the registered syntax and gives you every flag. The tradeoff is that a typo fails at runtime rather than when the script parses.

Deny a command to muted players:

on command:
    if command is "shop":
        if blazebans muted player:
            cancel event
            send "You cannot use the shop while muted."

Log warnings to a staff channel:

command /flagplayer <offline player> <text>:
    permission: staff.flag
    trigger:
        make console execute command "warn %arg-1% %arg-2%"
        send "Warned %arg-1%." to all players with permission "staff.notify"

Greet a player with an active warning:

on join:
    wait 1 second
    if blazebans warned player:
        send "You have an active warning. Reason: %blazebans ban reason of player%"

For real integration work, the BlazeBans API gives you the full surface: querying by ID, reading every field on a record, creating punishments with proof and scope, and cancelling or modifying punishments through events before they are stored.

Skript is the right tool for reacting to punishment state. The API is the right tool for changing how punishments work.