2
Use case and decision logic
This section determines whether your plugin genuinely needs API access and under what scope.
Short or vague answers are the most common cause of rejection.
Technical detection or decision mechanism*
"We detect hackers" or "we detect suspicious behavior" is not enough. Explain the actual
mechanism: network packet analysis? movement/combat heuristics? machine learning?
aggregation of player reports? staff-configurable rules? Include known false positives
in your own system and how you mitigate them.
Estimated or measured false-positive rate*
If you don't measure it formally, explain why and what proxy you use to estimate it.
Expected form volume on an average server*
Estimate forms per day on a mid-sized server (50-200 concurrent players). Be realistic, not optimistic.
Individual justification for each type checked above*
For each sanction type you checked, explain why your plugin specifically needs it. If you checked "permanent ban," this is the point that gets rejected most often without good justification — an anticheat rarely needs to permanently ban without human review.
Maximum sanction duration you're requesting (in hours)*
This value will be used as a hard ceiling in the configuration YAML — CraftersBan will automatically reject any sanction that exceeds this limit, no exceptions, even if your key is compromised.
Appeal system details (if applicable)
If you chose "none" above, explain how a false positive gets corrected today.
3
Security and cryptographic implementation
The Sanction API requires every form to be RSA-signed. This section evaluates whether your
team understands the security model before receiving a private signing key.
Technical context of the signing model:
Each sanction form is serialized as canonical JSON and signed with the RSA private key
we'd provide upon approval. CraftersBan verifies that signature with the corresponding
public key, declared in modules.yml. The public key can be seen by anyone
without compromising the system; the private key, on the other hand, is the only thing
that allows signing valid sanctions on your behalf.
How will the private key be stored inside your plugin?*
Be specific: a config file outside the .jar? an environment variable? the OS keystore?
an HSM? directly in the source code? This answer directly filters whether your team
understood the threat model: a .jar can be decompiled in seconds with free tools, so
any secret embedded there must be treated as public.
Protocol for suspected private key compromise*
What signals do you monitor to detect misuse of your own key? Who and how would you notify Crafters Development, and within what timeframe?
Internal validations before deciding to send a sanction*
What checks does your plugin perform before generating and signing a form? Is there a minimum confidence threshold, context review, or your own cooldown?
Past incidents of mass false positives or reported vulnerabilities*
If you've never had any, say so explicitly and explain why you believe that's the case. Concealing a publicly known incident is grounds for permanent rejection.
What do you expect to happen if your plugin exceeds the configured rate limit?*
Comprehension question: describe in your own words the technical consequence of exceeding the form limit per time window.
Crafters Development