Introduction - BloxCord V3

Every feature is exposed through a single BindableFunction named BloxCord, parented to game. One entry point, one call signature, zero HTTP boilerplate.

local BloxCord = game:WaitForChild("BloxCord")

local result = BloxCord:Invoke("methodName", arg1, arg2, ...)

The first argument to :Invoke() is always the method name (a string). The remaining arguments depend on the method and are documented per method in the API Reference.

What You Can Do

Ranking

Promote, demote, or move users through your group ranks.

Logbook

File warnings, suspensions, demotions, and more with full side effects.

Points & Reputation

Read balances, award points, and pull reputation scores.

Sessions

Host, mark, strike, and progress sessions straight from in-game.

Webhooks

Fire configured Discord webhook templates with dynamic data.

Batching

Bundle up to 20 operations into a single request.

Requirements

The BloxCord object only exists when the Org-Functions API is enabled for your organization. If it is disabled in the dashboard, the object is never created and game:WaitForChild("BloxCord") will yield forever.

Before you can use any method:

Install the BloxCord GameLink

The BloxCord V3.0 Communications script and its BloxCordInternal package must be present in ServerScriptService.

Enable Org-Functions

Turn on Org-Functions API in your organization dashboard. This is the master switch for every method listed in this documentation.

Wait for the object

The BloxCord BindableFunction is created asynchronously at startup, so always resolve it with game:WaitForChild("BloxCord") rather than indexing game.BloxCord directly.

A First Call

Here’s the simplest possible use of the API, fetching a player’s permissions the moment they join.

local BloxCord = game:WaitForChild("BloxCord")

game.Players.PlayerAdded:Connect(function(player)
    -- Fetch a player's permissions and print them
    local permissions = BloxCord:Invoke("getUserPermissions", player)
    print(player.Name, "has permissions:", permissions)
end)

How It Works

Most methods make a network round-trip to the BloxCord backend, so treat every call as yielding. Never call them inside tight loops or on the render step, and consider batching related work when you can.

Wrap calls that touch the network in task.spawn if you need the caller to keep moving, and always check the response shape documented per method before assuming a value exists.

​What You Can Do

Ranking

Logbook

Points & Reputation

Sessions

Webhooks

Batching

​Requirements

​A First Call

​How It Works

What You Can Do

Requirements

A First Call

How It Works