Fetch customer order + inventory context
GET /orders/{id} + GET /inventory/reservations
API Step
Resources / SDKs
Build worker-driven orchestration with Unmeshed SDKs.
Build in your preferred language, run workers and workflows in code, and ship tested releases confidently across environments.
Let's see a worker in action
Example flow: an order allocation workflow for an e-commerce service. First, an API step fetches order details and inventory state. Next, a worker function uses that data to run allocation logic in application code. Then the workflow moves to another API step to persist the worker output in a fulfillment system.
- API step retrieves operational context from upstream services.
- Worker step executes domain logic without exposing a public endpoint.
- Final API step publishes the worker result for downstream processing.
API to Worker Execution Path
Run allocation worker in application code
worker.allocateOrder(order, inventorySnapshot)
Worker Step
Persist allocation decision downstream
POST /fulfillment/allocations
API Step
When To Use SDKs
Use SDKs when your workflow steps need to execute application code that is not exposed as an endpoint. With the WORKER step type, your services poll for work, process typed input, return structured output, and let Unmeshed continue to handle orchestration concerns like scheduling, retries, timeout/error policy enforcement, and continuing the workflow as steps complete.
Tip
This pattern fits naturally with microservices architecture: services keep domain logic local, workflows handle cross-service coordination, and teams avoid endpoint sprawl while retaining loose coupling, independent deployability, and easier testing.
This removes the common requirement in orchestration systems to publish service endpoints just to invoke internal logic. Instead, SDK workers let you wire any language-specific function into a workflow directly, while keeping business logic in application code and flow logic in workflows. The model follows inversion of control: worker code stays focused on a single responsibility, and Unmeshed coordinates how each part is connected through the Workers concept.
How To Use SDKs
Step 1
Create Credentials
Generate client credentials for service-to-service authentication before connecting an SDK client.
Open docsStep 2
Implement Workers
Author worker functions in your language SDK and bind them to workflow step names.
Open docsStep 3
Run and Validate
Run in development, validate behavior with test workflows, and monitor process/step output.
Open docsStep 4
Promote to Production / Live
Version your definitions and application code together, then promote tested artifacts across environments.
Open docsSupported SDKs
Each SDK supports worker registration and workflow execution so teams can keep orchestration inside their preferred language runtime.
JavaScript / TypeScript SDK
Build Node.js workers, execute workflows sync/async, and manage process lifecycle directly in application code.
Open JavaScript / TypeScript SDK
Python SDK
Register sync and async worker functions, configure polling/concurrency, and run production workflows from Python services.
Open Python SDK
Java SDK
Use annotation-based workers, access execution context, and manage process definitions with strong typed Java patterns.
Open Java SDK
Golang SDK
Run lightweight workers, tune throughput with client configs, and operate workflow definitions from Go-based systems.
Open Golang SDKComing Soon
Additional SDKs in progress
We are actively expanding the SDK lineup and will publish documentation as these become generally available.
C# SDK
Planned SDK for .NET services and enterprise backend ecosystems.
Rust SDK
Planned SDK for high-performance, low-footprint workflow workers.
Developer First
Get started with Unmeshed
Launch quickly with Unmeshed, orchestrate reliable workflows, and use SDK workers where custom application logic is needed.