Publish from your coding agent

First submission

1. 1

   get_submission_requirements - Learn the rules, required fields and K.O. criteria.

2. 2

   precheck_build - Dry-run the submit gate and fix missing files or the marker before spending a review cycle.

3. 3

   submit_new_software - Metadata plus the build. Pass the storage_path from the precheck so the ZIP travels only once.

4. 4

   upload_screenshot - At least 2 screenshots (at least 640 x 360 px). The review approves the software on its own; the listing goes on the market once the screenshots are in. check_review_status attests the presentation level and lists what makes it ideal (logo, 4 screenshots in Full HD, video).

5. 5

   check_review_status - Poll until the review completes, then read get_review_report, fix the findings and resubmit.

Shipping analytics or telemetry? Set privacy_policy, name the service in it and declare its server in the network list. The review lists trackers it finds as notes; the launcher only lets the app reach the declared servers.

New versions

Ship a new build with update_software (software id, build ZIP, version, os, arch). Versions are semver. A release build goes through the review again; channel: "demo" publishes a demo without touching the live listing. Paid tools embed the SDK marker from get_sdk_marker first (see Copy Protection). Lost a software id? list_my_software returns all of them.

Authentication

All endpoints except GET /api/agent/requirements require a Bearer token.

Authorization: Bearer crela_<your-api-key>

Create keys in your creator dashboard. The full key is shown once on creation. Keys have the prefix crela_.

Quickstart

Submit your first tool in 5 steps:

curl https://crela.io/api/agent/requirements

# framework / entrypoint / install_type / platforms / license are
# detected by the server from the build ZIP. You only send marketing content
# plus the ZIP.
curl -X POST https://crela.io/api/agent/software \
  -H "Authorization: Bearer $CRELA_API_KEY" \
  -F "file=@dist/myapp-build.zip" \
  -F "title=My App" \
  -F "slug=my-app" \
  -F "description=A short description" \
  -F "long_description=Full markdown description" \
  -F 'categories=["tool"]' \
  -F "price_eur=0" \
  -F "version=1.0.0" \
  -F "system_requirements=Windows 10+"

# Response: { "id": "tool_abc123", "slug": "my-app", "status": "pending_review" }
TOOL_ID="tool_abc123"

# Repeat every 30 s until review_job_status != "running"
curl https://crela.io/api/agent/software/$TOOL_ID/review \
  -H "Authorization: Bearer $CRELA_API_KEY"

Get Requirements

Machine-readable schema with submission constraints, K.O. criteria, quality guidelines, and content rules. Fetch before every submission.

{
  "schema_version": "1",
  "submission": { /* required/optional fields, types, constraints */ },
  "ko_rules": [ /* 12 hard-rejection rules (KO-01..KO-12) */ ],
  "quality_guidelines": { /* 5 scored evaluation categories */ },
  "content_rules": { /* allowed/blocked URLs */ }
}

Build format: portable builds only

Crela accepts portable builds only - no setup wizard, no installer. Windows and Linux builds (AppImage/ELF) get the full review including the test run. macOS builds are accepted, but get no test run.

Allowed formats

• ✦ZIP archive with EXE and dependencies (folder portable, Windows)
• ✦Single EXE (PyInstaller onefile, Go static, Rust static)
• ✦.NET single-file self-contained (AOT or JIT)
• ✦Java fat JAR or JLink bundle
• ✦Electron / asar as ZIP
• ✦Tauri bundle as ZIP (Windows)
• ✦AppImage (Linux - recommended, because the frontend is extracted alongside)
• ✦Linux ELF + companion files as ZIP (limited - for Tauri or Electron builds the embedded frontend is brotli-compressed, so the pipeline cannot inspect it)

Automatically rejected

• ✕NSIS installers (e.g. *Setup.exe, *-installer.exe)
• ✕InnoSetup (*Setup.exe)
• ✕MSI and MSIX
• ✕WiX-generated installers
• ✕Self-extracting setup wrappers - even if the result would be portable
• ✕macOS .dmg images
• ✕macOS .pkg packages (XAR)
• ✕Linux .deb packages
• ✕Linux .rpm packages

The rule applies to the program you submit: it must run directly without installation. Helper setups bundled next to it are allowed, for example the Microsoft Visual C++ runtime installer (vc_redist.exe) or an optional driver setup.

Supported frameworks

Your framework is not on the list? Contact support - we will review adding it. No automatic reject.

List Software

All tools you own with id, slug, status, version, price, unlisted flag and sales count, newest first. Optional query: status filter and limit (1 to 100, default 50).

Precheck Build

Dry run of the submit gate: framework detection, bundle completeness, SDK marker (KO-10) and file limit. Creates no listing and starts no review. Send file or a storage_path from Presign Upload, plus slug and price_eur; framework, entrypoint and platforms are optional overrides. The upload stays available, so the same storage_path can go straight into submit or a build update.

Submit Software

Submit a new software listing.

Required fields

Auto-detected fields (the server reads them from the ZIP, optional creator override possible)

Conditional fields

Optional fields

Response 201 Created

{
  "id": "tool_abc123",
  "slug": "my-app",
  "title": "My App",
  "created_at": "2025-01-01T00:00:00.000Z",
  "status": "pending_review"
}

Get Software

Fetch full metadata and media list for a tool you own, in any status.

{
  "tool": {
    "id": "tool_abc123",
    "slug": "my-app",
    "title": "My App",
    "status": "approved",
    "version": "1.0.0"
    /* ... all metadata fields */
  },
  "media": [
    { "id": "m1", "type": "screenshot", "url": "https://...", "sort_order": 0 }
  ]
}

Permanently delete a tool including builds and media. Only possible if it was never sold; otherwise 409 - unlist it with PATCH { "unlisted": true } instead, buyers keep their access.

Update Metadata

Partial update of metadata. Changing brand fields (title, description, categories, age rating) on an approved tool, or raising the price from free to paid, automatically queues a re-review. The tool stays on sale with its current details until the review approves the change; until then the change is listed in pending_changes. A rejected change is discarded.

Patchable: title · description · long_description · categories · tags · price_eur · sale_price_eur · sale_ends_at · max_devices · system_requirements · license · tool_languages · platforms · install_type · privacy_policy · support_contact · security_updates_until · safety_notes · drm_mode · video_url · framework · requires_system_rights · unlisted · trial_enabled · trial_days · network_mode · network_hosts · age_rating · age_rating_source · age_rating_reasons · age_rating_questionnaire

// Request body (any subset)
{ "description": "Updated short description", "price_eur": 4.99 }

// Response
{
  "ok": true,
  "updated_fields": ["description", "price_eur"],
  "triggered_re_review": false,
  "new_status": "approved",
  "pending_changes": null
}

Update Build

Upload a new build of an existing tool. The same gates as on submit run first (file limit, bundle completeness, SDK marker). The ZIP is then unpacked server-side, files are deduplicated by SHA-256, a signed manifest is stored and the review pipeline is triggered. A release build sends the tool back to status="pending" until approved. This is the endpoint behind the MCP tool update_software.

Max 2 GB per ZIP, max 500 MB per file, max 200 executable files. For large builds upload via Presign Upload and send storage_path instead of file. Automatically unpacked portable containers: .asar (Electron), .jar (Java), .AppImage (Linux), PyInstaller bundles. Plain binaries are scanned directly. Classic installers (NSIS, MSI, InnoSetup, DMG, PKG, deb, rpm) are hard-rejected by KO-12 - only portable builds are allowed.

Fields

curl -X POST https://crela.io/api/agent/software/$TOOL_ID/build \
  -H "Authorization: Bearer $CRELA_API_KEY" \
  -F "file=@dist/myapp-build.zip" \
  -F "version=1.1.0" \
  -F "os=windows" \
  -F "arch=x86_64"
# Optional: upload a demo build (does not change the live tool)
#   -F "channel=demo"

# Response
{
  "build_id": "3090e2f5-bdf1-4842-9dae-ab4f38d7acb1",
  "tool_review_id": "...",
  "manifest_sha": "6ebbf8ab...",
  "total_files": 12,
  "total_bytes": 9052672,
  "channel": "release",
  "status": "pending_review"
}

Build Distribution

What happens to your files, from your upload to the buyer's disk. Every file is identified by its SHA-256 hash, and the list of all files is signed, so nobody can swap a file on the way without it being noticed.

1. Upload: You upload the build folder as a ZIP. The server computes the SHA-256 of every file, stores each file under its hash and writes a manifest (path, hash and size of every file) that it signs with Ed25519.
2. Review: The review checks every file against that signed manifest and then runs the review process. Only the build that passed is released; a later upload never replaces it unreviewed.
3. Delivery: The Crela launcher fetches the manifest, verifies its Ed25519 signature with the public key built into the launcher, downloads the files it does not have yet and checks each one against its hash before it assembles the folder.
4. Updates: Files are stored once per hash. An update uploads and downloads only the files that changed; unchanged DLLs and assets are reused.
5. Cleanup: A rejected build is kept for 90 days, so it can still be reviewed again, and removed after that. Approved builds are never deleted by this cleanup, so buyers keep what they paid for.

Presign Upload

Signed URL for a direct upload to R2 - useful for large build ZIPs (over 100 MB). You PUT the ZIP to the returned upload_url and then pass storage_path instead of file to precheck, submit or a build update. Framework and entrypoint are detected from the uploaded ZIP as usual.

// Request
{ "filename": "myapp-1.0.0.zip", "file_size_bytes": 12345678 }

// Response
{
  "upload_url": "https://storage.crela.io/...",
  "storage_path": "uploads/abc123/myapp-1.0.0.zip",
  "expires_at": "2025-01-01T01:00:00.000Z",
  "method": "PUT",
  "headers": { "Content-Type": "application/zip", "Content-Length": "12345678" }
}

Review Results

Latest review result. Poll every 30 s while review_job_status is queued or running.

// Pending
{ "status": "pending", "review_job_status": "running", "retry_after_seconds": 30 }

// Approved
{ "status": "approved", "passed": true, "rejection_reason": null,
  "review_report": { /* structured feedback */ } }

// Rejected - use rejection_reason to fix and resubmit
{ "status": "rejected", "passed": false,
  "rejection_reason": "Binary triggers K.O. rule: missing core functionality",
  "review_report": { /* detailed feedback */ } }

Quick Status

Lightweight status check including rate-limit quota.

{
  "tool_id": "tool_abc123",
  "tool_status": "approved",
  "version": "1.1.0",
  "review_job_status": "completed",
  "review_sub_step": "completed",
  "review_passed": true,
  "rate_limit": {
    "updates_used_today": 2,
    "updates_remaining_today": 3,
    "window_resets_at": "2025-01-02T00:00:00.000Z"
  }
}

Media Management

API Keys

The 12 phases

1. 1
   Loadingdownloading

   We fetch every file of your build from storage, exactly as you uploaded it.

   Technical details

   Downloads every file of the build tree, including debug symbols if bundled.

2. 2
   File checkextracting

   We unpack portable containers (Electron, Java, PyInstaller, AppImage, .NET single-file, Tauri) so the later checks see the actual code, not just the wrapper around it.

   Technical details

   Bundle auto-extract for portable containers: asar (Electron), jar (Java), PyInstaller, AppImage, .NET single-file bundles (also compressed), Tauri frontends. Classic installers (NSIS/MSI/DMG/PKG/deb/rpm) are hard-blocked as KO-12 in pre_scan.

3. 3
   File integrity checkmanifest_consistencyCan block approval

   Every file is compared with the signed manifest made at upload, so nothing was swapped, lost or added on the way. Blocks if a file is missing, extra or changed, or if a file your program needs to start is missing.

   Technical details

   SHA-256 of every file against the signed build manifest. Findings: MISSING-FILE, EXTRA-FILE, SHA256-MISMATCH, ENTRYPOINT-MISSING, plus the bundle check for files the program needs to start, such as startup DLLs (BUNDLE-INCOMPLETE). All of them block approval.

4. 4
   Static checkpre_scanCan block approval

   We pick the files to check and detect installer formats by their magic bytes. Blocks if the submitted program itself is a classic installer (KO-12); bundled helper setups such as runtimes or drivers are only listed.

   Technical details

   Selects the check targets (entry point, executable files, scripts, possible installer files) and detects installer formats (KO-12: NSIS/MSI/InnoSetup/Squirrel/Velopack/DMG/PKG/deb/rpm and more). If the submitted program itself is an installer: blocks_approval=true, severity=critical; bundled helper setups (runtime, driver) are only listed. The KO pattern search runs once, in source_pattern.

5. 5
   Binary inspectionstatic_binary_analysisNever blocks on its own

   Every executable is matched against about 2,000 YARA rules for known malware, without starting it. A hit never blocks on its own: the AI review weighs it, because generic rules also match harmless code.

   Technical details

   PE header parse per file (imports, sections, subsystem) - Windows binaries only. YARA scan across all executable files against the malware-family rules of signature-base and elastic/protections-artifacts (about 1000 rule files). A YARA match is a finding for the review, not a rejection on its own.

6. 6
   Security scanvirus_scanCan block approval

   Every executable is scanned with ClamAV on our own server and its hash and URLs are looked up in MalwareBazaar and URLhaus. Blocks on any detection.

   Technical details

   ClamAV INSTREAM for all executable files. In parallel: threat intel via MalwareBazaar + URLhaus (abuse.ch) for the file hash and the URLs found in the build. If ClamAV cannot scan a file, the build is not passed.

7. 7
   Dependency mapsbom_generation

   We list the libraries and packages in your build, like an ingredient list. It is a tool for our vulnerability check, not your SBOM, and only you can read it.

   Technical details

   Syft produces a CycloneDX SBOM over the entire build tree and stores it with the build. It feeds the vulnerability check and the daily re-check, and only the creator can read it.

8. 8
   Vulnerability checkcve_scanCan block approval

   Each library is checked against OSV.dev for known vulnerabilities. Only a high or critical one you can fix blocks: a fixed version exists for your platform and the affected file is really in your build. Everything else is a warning.

   Technical details

   OSV.dev scan against the SBOM from phase 7 - also works for pure binaries. KO-06 only for vulnerabilities from HIGH upwards with a fixed version in the ecosystem of the build (for Debian/Ubuntu the release, compared like dpkg; release unknown: every affected release needs a fix) and, for distro packages, when the vulnerability text names a file the build ships from that package (Syft locations). Everything else is a warning with the reason.

9. 9
   Test runsandboxNever blocks on its own

   When a Crela review machine is available, we start your program in disposable VMs without network, check that it starts and opens a window, and click through it. Otherwise this phase is skipped and run later. Its observations never block on their own.

   Technical details

   Test run of the entrypoint on a Crela review PC. Windows builds get a deep run on up to 6 Hyper-V Windows test VMs in parallel (each reset to a clean snapshot); a manual short test run uses one of them. If the test VMs are busy, the run waits for them; if they are not set up or out of disk space, Windows builds get no test run. Linux builds get the deep run in a Hyper-V VM reset to a clean snapshot. All without network and with the build mapped read-only, started like the Crela Launcher (license, working directory). Checks at 8 s and 60 s: started, still running, main window, error dialogs, crash exit code, license failure; afterwards new files and registry entries (Windows: AppData, ProgramData, HKCU, Run and Uninstall keys; Linux: the home folder including autostart entries, shell startup files and the user crontab). Only what belongs to the app counts: caches that Windows, graphics drivers or shared libraries write for every app are left out. Links it hands to the system (browser, store protocols such as ms-windows-store:) go to a recorder and are never opened; requested servers are recorded by a local proxy that refuses every connection; the window text comes from UI Automation (Windows) or AT-SPI (Linux). Once the app has started, it clicks through the app (menus, buttons, tabs, list items via UI Automation or AT-SPI) and builds an app tree of the screens it reaches, with the click path to every store link; it never clicks elements named like delete, buy, sign out or uninstall and stops at login screens. The deep run has a time limit: on the test VMs the machines share a queue of click paths and the run ends after at most 9 minutes, with no new paths handed out close to the end; otherwise one machine clicks through for at most 5 minutes. Large apps are therefore covered only in part. Window text, opened links, requested servers and the Procmon log of the app process tree (Windows only) are combined from all machines, and admins get an app map with screenshots of the screens it reached. Linux packages (.AppImage/.deb/.rpm/.sh) are also unpacked and their scripts inspected in a hardened container (--network=none, --cap-drop=ALL, read-only); a .deb or .rpm submitted as the program itself is still rejected as an installer (KO-12). The pipeline waits as long as the review PC is working on the run, at most 20 minutes; if the review PC is offline, the phase is skipped and the run is queued for later. Observations from the test VMs never block approval on their own; only a malicious script inside a Linux package does (KO-01). macOS builds are skipped (no VM backend).

10. 10
    Pattern analysissource_patternCan block approval

    Every text file and script of the unpacked build is read in full for trackers, ads, payment prompts, hidden crypto-mining and leaked secrets. Blocks on a verified secret or a Tauri frontend we cannot unpack; other hits go to the AI review.

    Technical details

    Pattern scan against the KO criteria over every text file of the unpacked bundle and loose scripts, each file in full (large files in overlapping blocks, no size cap), including containers nested in containers (e.g. app.asar or a Tauri frontend inside an AppImage), plus TruffleHog. For verified secrets, blocks_approval=true. KO-08 only flags hidden crypto-mining code (mining pool address, xmrig, coinhive). Hits inside bundled framework runtimes (Chromium, Qt, ICU, CPython, .NET ...) are recorded as runtime hits and never block.

11. 11
    AI reviewagentCan block approval

    An AI (Claude) reads your description and all findings so far and judges the K.O. rules KO-01 to KO-10, for example whether the description matches the program and whether a paid tool has the Crela SDK marker.

    Technical details

    A deterministic pre-decision runs first: clean non-binaries are approved and clear pattern hits are rejected without an LLM call; KO-10 (SDK marker in paid tools) and the KO-07 description mismatch below the similarity threshold are decided deterministically. Everything else goes to an LLM agent (Claude; the model is configurable, a larger one is used when there are blocking findings or app-own hits for KO-03/04/05) that evaluates all preceding phase results. Content taken from the build is fenced as data. The agent may tighten a verdict, never loosen it: every blocking finding from the scan phases forces a reject. KO-09 (undisclosed telemetry) never blocks and is reported as a note, because the launcher enforces the declared servers at runtime. KO-11 (self-updater) and KO-12 (installer format) are already detected in the scan phases - KO-12 hard-blocks (pre_scan, magic bytes).

12. 12
    Final reportbuilding_report

    All results are combined into one report. Any blocking finding from an earlier phase turns the result into reject, even if the AI recommended approval.

    Technical details

    Aggregates the agent verdict with a blocking override: every blocking finding from the scan phases (medium severity or higher) forces reject, even on agent approve. The structured report is returned as review_report by the review endpoint.

What we never do

• We never change your build: no patching, repacking or injecting. The SDK marker is something you build in yourself.
• Your program only runs in disposable virtual machines, reset to a clean snapshot for every run, with no network and your build mounted read-only.
• Links your program opens are written down and never opened. Every connection it attempts is refused and only recorded.
• The dependency list we create from your build is readable only by you.

Limits

• A passed review lowers the risk, but it is not a guarantee. Scanners recognize known malware and known patterns; something entirely new can slip through.
• The test run needs an available review machine. Otherwise it is skipped and done later. macOS builds get no test run.
• The test run clicks through the app within a time limit, so large apps are covered only in part. It is a test run, not a full behavioral analysis.

Result and next steps

We only reject what is certain and what you can fix yourself. A vulnerability blocks only when a fixed version exists, observations from the test run never block on their own, and generic YARA hits go to the AI review instead of rejecting you. Every finding in the report names the file and a suggested fix, and a rejection always comes with the full reasons by email.

Read the report with Review Results or the MCP tool get_review_report. Uploads per day are listed under Rate Limits.

Fetch the marker

Via MCP: preview_marker for a planned slug before the first submission, get_sdk_marker for an existing tool. Via REST:

{
  "tool_id": "tool_abc123",
  "slug": "my-app",
  "marker": "CRELA_SDKv2_abc123...",
  "notes": "Embed via CRELA_SDK_MARKER env var before build"
}

Embed in your build

For Node.js / Electron projects use the init CLI - it fetches the marker, injects the SDK call, and patches your bundler config automatically:

cd your-tool/
npx @crela/init

For CI/CD pipelines or other runtimes (Rust, .NET, C++) fetch and embed manually:

# Fetch marker and inject before build
export CRELA_SDK_MARKER="$(curl -s https://crela.io/api/agent/software/$TOOL_ID/sdk-marker \
  -H "Authorization: Bearer $CRELA_API_KEY" | jq -r '.marker')"

npm run build   # Your build reads CRELA_SDK_MARKER at compile time

For integration examples - Node.js/Electron and Rust/Tauri, plus how other languages embed the marker without an SDK - see the Creator Guidelines.