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 3 images; the review scores the presentation on them.

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 and name the service in it - KO-09 rejects builds that contact a tracker the policy does not mention.

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. Primary support: Windows; Linux builds (AppImage/ELF) are accepted, macOS support is in progress.

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

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) on an approved tool automatically queues a re-review.

Patchable: title · description · long_description · categories · tags · price_eur · sale_price_eur · sale_ends_at · max_devices · system_requirements · license · tool_language · platforms · install_type · privacy_policy · support_contact · drm_mode · video_url · framework · requires_system_rights · unlisted · trial_enabled · trial_days

// 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"
}

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 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

Builds are delivered as content-addressable file trees - comparable to Steam's depot model, but at the file level (no chunk splitting).

• Upload: The creator zips the build folder. The server hashes each file (SHA-256), uploads only missing hashes to R2 under content/<sha[0:2]>/<sha[2:4]>/<sha>, builds a manifest with paths + hashes + sizes, signs it with Ed25519, and stores manifest + signature in DB + R2.
• Dedup: Identical files (e.g. unchanged DLLs between versions) exist physically only once in R2. An update to v2.0 uploads only the changed files.
• Multi-file review: The worker downloads ALL files in parallel (concurrency 8, cap 200), checks each SHA-256 against the manifest via manifest_consistency, and routes every executable file individually through virus_scan (ClamAV INSTREAM), static_binary_analysis (YARA against ~2007 signature rules, plus a PE header parse for Windows binaries), and source_pattern (bundle auto-extract + Semgrep + TruffleHog). sbom_generation via Syft runs once over the entire build tree, cve_scan on the resulting SBOM (OSV.dev). sandbox (capa capability analysis, no execution) + LLM agent run only on the entrypoint, but the agent receives all phase B findings as context in the system prompt.
• Blocking logic: Phase B findings with blocks_approval=true (e.g. MANIFEST-SHA256-MISMATCH, CLAMAV-DETECTION, verified TruffleHog secrets) override the agent verdict and force reject, even if the agent would have recommended approve.
• Launcher download: The Crela launcher calls GET /api/tools/{id}/build/{version}/manifest, verifies the Ed25519 signature with the public key compiled into the launcher, downloads missing blobs (cache-aware), checks each file individually against the manifest hash, assembles the tree, and writes an install manifest.
• Reject cleanup: When an admin rejects a build, all storage artifacts (R2 blobs, manifest, DB rows) are removed automatically. Orphan blobs are cleaned up via a refcount trigger.

Schema: content_blobs, tool_builds, build_files, tool_build_sboms, pipeline_findings (migrations 060_build_manifests.sql, 061_pipeline_v2.sql).

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

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.