Project: OrcaSlicer HTTP API Wrapper

Contact: https://t.me/dantetemplar

Background

We need a way to slice 3D models programmatically from a Python backend, without any manual GUI interaction. Initially this was attempted with CuraEngine, but in practice it turned out to be hard to configure, debug, and run reliably in a headless environment.

OrcaSlicer, on the other hand, provides a modern slicing pipeline, good default profiles, and an active community. However, it is primarily a desktop GUI tool. The goal of this project is to wrap OrcaSlicer into a small, well-documented HTTP service that can be called from other systems, especially Python-based backends.

The primary application on our side is to generate toolpaths not for a typical desktop 3D printer, but for a large manipulator used in additive manufacturing. From the API perspective, this is “just another machine profile”, but this is the context in which the service will be used.

Prior Work and Motivation

Based on this discussion there are at least two related open projects:

• AFKFelix/orca-slicer-api
  A TypeScript REST API with a nice OpenAPI schema. It works out of the box for .3mf projects exported from OrcaSlicer. It claims to support profiles, but in practice requires manually uploading all default profiles (not only user-defined ones), which makes it inconvenient for general use. I have forked it and experimented with it: https://github.com/dantetemplar/orca-slicer-api.

• LukaCek/slice_api
  An example Python API for print price calculation. It allows choosing print quality and then slicing using predefined BambuLab profiles. It returns a price, .3mf file, and G-code. The code is more of a prototype and is tightly focused on that specific use case.

Both of these projects are designed to run via Docker setups, which greatly simplifies the environment and dependency management for OrcaSlicer-based services.

This task takes inspiration from these projects (REST API around OrcaSlicer, OpenAPI schema, Python integration, Docker-first deployment), but aims to produce a cleaner, more general, and better documented solution.

Task

Design and implement an open-source HTTP API wrapper around OrcaSlicer that can be used as a standalone slicing service. All detailed API design decisions (endpoint layout, request/response schemas, error model, internal data model, etc.) are up to the author, as long as the capabilities below are covered and documented.

The project must be released under the MIT license.

The service is expected to be packaged and run only via Docker (e.g., Dockerfile + docker-compose.yml or similar), following the approach of the existing projects mentioned above.

Functional Scope

The service should:

1. Expose OrcaSlicer as an HTTP API

   • Headless service that can be run and deployed as a Docker container.
   • The service is responsible for orchestrating OrcaSlicer calls and managing temporary files.
   • The primary supported deployment method is via Docker; local bare-metal setups are not required.

2. Support input formats

   As input, the API must accept models/projects in the following formats:

   • .stl
   • .step
   • .3mf

3. Provide outputs

   For a slicing request, the API must be able to return:

   • G-code.
   • .3mf project (with applied profile/settings).
   • Print metadata (e.g., estimated time, material usage, layer count, etc.) in a machine-readable format such as JSON.

   The exact structure of the metadata is up to the author, but it should be documented.

4. Handle profiles

   The API must work with slicing profiles in a way that covers:

   • Using standard/default OrcaSlicer profiles.
   • Creating and saving new profiles.
   • Updating and deleting custom profiles.
   • Applying temporary overrides of individual settings for a single slicing job (without permanently changing the underlying profile).

   The internal representation of profiles, storage mechanism, and how they are referenced through the API (IDs, names, etc.) are up to the author, but must be clearly described in the documentation.

5. Allow per-request setting overrides

   • It should be possible to modify specific slicing parameters for a single job (e.g., layer height, infill) without persisting those changes to any profile.
   • The mechanism (e.g., a separate “overrides” field in the API) is up to the author.

6. Provide documentation and OpenAPI/Swagger

   • The API must have a clear, machine-readable OpenAPI (Swagger) schema.
   • There should be an interactive Swagger UI (or equivalent) for manual exploration and testing.
   • The documentation must describe:
     • Available endpoints.
     • Main request/response formats.
     • How profiles and overrides work.
     • Example flows (e.g., “upload model → choose profile → slice → download G-code”).

7. Provide a Python client

   • A small Python library that wraps the HTTP API and exposes a convenient interface for common operations (e.g., slicing a file with a chosen profile).
   • The client should:
     • Handle basic configuration (base URL, timeouts, etc.).
     • Surface server errors in a meaningful way (with exceptions and access to error information).
   • The author is free to choose the error and exception model, but it should be consistent and documented.

8. Logging and errors

   • The server should log requests and slicing operations in a way that helps debug issues (e.g., what profile was used, which file was sliced, whether OrcaSlicer failed).
   • The API should return clear error responses for typical failure cases (invalid input, missing profile, slicer failure, etc.).
   • The exact logging format and error schema are up to the author, but they should be described briefly in the documentation.

Non-Functional Expectations

• The project should be reasonably structured and maintainable.
• The only supported way to run the service should be via Docker:
  • Provide a Dockerfile that builds a runnable image with OrcaSlicer and the API server.
  • Optionally provide a docker-compose.yml for local development/testing.
  • The README should include a short “Quickstart” showing how to build and run the container and how to access the API and Swagger UI.
• Host OS–level manual setup instructions are not required, as long as the Docker setup is self-contained and documented.

Deliverables

• Source code of the HTTP API server that wraps OrcaSlicer.
• Docker-based setup (at minimum: Dockerfile, plus any scripts needed for container startup).
• OpenAPI/Swagger specification and interactive docs.
• Python client library with basic usage examples.
• Documentation (README or separate docs) explaining:
  • Background and motivation.
  • How to build and run the Docker image/container.
  • How to use the API and Python client to:
    • List/use/create/update/delete profiles.
    • Slice models in supported formats and retrieve outputs.
• MIT license file in the repository.