Settings

The optimization level controls how much of the source the prepare stage is allowed to discard before the pipeline proper starts. Higher levels remove more, which makes the artifact harder to read and slightly smaller, but also removes material some codebases still depend on at runtime.

Level 1 is the default. It removes assert statements and injects junk code, and level 2 does the same while also removing docstrings. Level 0 leaves the source untouched and injects no junk code. Only these three levels are accepted, so any other value is rejected before a build starts.

The target version is the interpreter the artifact is built for. Five versions are accepted, and the default is the newest of them.

The artifact carries a version lock over interpreter minor version, operating system, architecture and pointer size. Running it under anything other than the exact combination it was built for fails immediately with a clear error, rather than misbehaving further into execution.

The anti-debug tier selects which runtime detection layers are embedded in the artifact. Values are lowercase, and medium, high and extreme map onto the engine tier switches, so a tier you pick here is the same tier the engine reaches by its own flag.

The remaining switches control layout, format and the privacy layers. All of them are booleans except icon, which is a path. Each row shows its default in the Default column, and the same defaults apply when a submission omits the key entirely.

The lowering pass moves the call sites of Python builtins out of the interpretable source and into the native kernel. The fourteen families are independent booleans. Nine are on by default, and the remaining five are opt-in.

Two string settings bind a build to a machine or to a deadline. Both are empty by default, which means no licensing layer is applied and the artifact runs anywhere.

Both can be set on the same build, giving an artifact that runs only on the authorised machine and only until the deadline. The deadline is bound to the build, so moving it to another machine breaks the trial rather than extending it, and a clock rolled backwards is detected.

Every path into the engine takes the same object. Over HTTP it is a JSON string in the settings field of the multipart body. The dashboard exposes the same keys as controls, so anything you can set in a request you can also set on the page.

curl -X POST https://nyami.cc/api/obfuscate \
  -H "X-API-Key: nyami_your_key_here" \
  -F "file=@script.py" \
  -F 'settings={
    "optimization": "1",
    "python_version": "3.14",
    "anti_debug": "high",
    "var_renaming": true,
    "mixed_format": true,
    "zip_light": true,
    "windows_target": true,
    "pytoc": false,
    "hwid": "S-1A2B-3C4D-5E6F-7A8B",
    "trial_time": "7d"
  }'

import json
import requests

settings = {
    "optimization": "1",
    "python_version": "3.14",
    "anti_debug": "high",
    "func_obf": True,
    "zip_pyc": True,
    "drv": False,
    "trial_time": "7d",
}

with open("script.py", "rb") as handle:
    response = requests.post(
        "https://nyami.cc/api/obfuscate",
        headers={"X-API-Key": "nyami_your_key_here"},
        files={"file": ("script.py", handle, "text/x-python")},
        data={"settings": json.dumps(settings)},
        timeout=60,
    )

print(response.json())

The response carries a job id, not the artifact. Poll the job until it reports COMPLETED, then fetch the signed download URL it returns. The endpoint contract and every error it can raise are on the API page.