No-Code API vs. Lua SDK vs. AI Assistant

Three ways to build custom detections.

Wire up existing FiveM events visually, call Parity straight from your own Lua, or just describe the rule to an AI assistant and let it build the rule for you. Same actions, same enforcement pipeline — pick what fits your workflow.

No-Code API

Custom API Rules

Connect FiveM events to Parity actions with a visual node editor in the dashboard. No Lua required — pick a trigger, gate it behind a check against your own resource, add up to 5 actions.

Best for

Wiring up existing events without writing code, or letting an admin without Lua experience build and toggle rules themselves.

Read the Custom API Rules docs

Lua SDK

Server-side exports

Call Parity directly from your own resources. Four exports cover the entire pipeline: capture evidence, then log, kick, or ban — with full control over when and why.

Best for

Embedding checks directly inside scripts you already maintain, or logic too custom for a visual editor (loops, your own database, third-party APIs).

Read the Lua SDK docs

AI Assistant

Parity MCP

Describe the rule in plain English to Claude, Cursor, or any MCP-capable assistant. It builds a No-Code rule for you through the same API the dashboard uses — you just review and switch it on.

Best for

Server owners who don't want to hand-build the rule at all — including one-shot tools that whitelist a false positive or collapse twenty rules into one catch-all check.

Read the Parity MCP docs

“I'm not a developer”

→ No-Code API

Click through the node editor in Configuration → Custom API Rules. No Lua, no restart.

“I already maintain Lua resources”

→ Lua SDK

Call sdk_ban / sdk_kick / sdk_log straight from the script you already have open.

“I'd rather just describe what I want”

→ AI Assistant

Tell your assistant what to whitelist or enforce — it writes the No-Code rule through the API.

Every action, both ways.

No-Code flow

Event Handler

myServer:illegalWeapon · Params: weaponName

Export Check

myScript:IsPlayerCheating(source, weaponName)

Ban Player

Reason: "Illegal weapon: [weaponName]" · Screenshot + video

Lua SDK

server/detections.luaparity_anticheat

Citizen.CreateThread(function()
    local evidence = exports["parity_anticheat"]:sdk_captureEvidence(source, {
        captureScreenshot = true,
        captureVideo      = true,
    })

    exports["parity_anticheat"]:sdk_ban(source, "Cheating", {
        reason = "Aimbot detected",
        info   = "Detected during combat",
    }, {
        detectionType     = "aimbot",
        captureScreenshot = false,
        screenshotMediaId = evidence and evidence.screenshotMediaId or nil,
        videoMediaId      = evidence and evidence.videoMediaId or nil,
    })
end)

No-Code API

Lua SDK

Setup

Visual flow editor in the dashboard

Server-side Lua exports in your resource

Trigger source

FiveM events + export checks

Anywhere in your own script logic

Actions

Ban Player, Kick Player, Log Only nodes

sdk_ban, sdk_kick, sdk_log

Evidence

Screenshot/video toggle per node

sdk_captureEvidence, pass media IDs manually

Restart required

Best for

Wiring existing events without writing code

Embedding checks directly in your own scripts

The AI Assistant isn't a fourth pipeline — it drafts and saves a rule in the No-Code API column above through the same public API the dashboard uses.

Common questions

Yes. All three feed the same enforcement pipeline and the same Events tab — a No-Code rule, an sdk_ban call from your own script, and a rule an AI assistant drafted can all be active on the same server without conflicting. The only thing to watch: if you edit the same rule in the dashboard and through the API/assistant at the same moment, whichever write lands last wins — review important changes afterwards.

No. No-Code rules save straight to the dashboard and push to your live server immediately. Lua SDK calls are just exports in a resource you control, so they follow your own resource's restart cycle, not Parity's.

The rule is still saved in Parity — the editor shows a "not synced" state until the server reconnects. On its next boot or reconnect, the anticheat automatically re-pulls the current rule set, so nothing is lost; just re-test once the server is back.

With the Lua SDK, yes by default — you're the one calling sdk_ban/sdk_kick/sdk_log, so you already have the context. With the No-Code API, add the detection's details as export arguments (exports['myac']:isAllowed(source, detectionType, details)) and Parity fills them in from the live detection — see "Passing the detection to your export" in the Custom API Rules docs.

Only for live actions — testing a rule against an online player, kicking/messaging someone, reading online players or server stats. Drafting and saving a rule works regardless; it's stored in Parity the same way a rule you build by hand is.