Service API reference
The core discovery and solve routes, request fields and integration boundaries.
Core routes
These routes are present in the solver server source. Use your provisioned base URL and its matching generated SDK/OpenAPI contract. Enabled capabilities and authorization vary by deployment.
GET /api/v1/manifests
GET /api/v1/manifests/{problem_type}
POST /api/v1/solve/{problem_type}
GET /api/v1/solve/{job_id}Public request fields
problem carries the structured domain input. solver carries solver configuration. options carries execution options. context, when supplied, must satisfy the deployment’s invocation admission contract.
problem_type belongs in the route. The internal SolveRequest includes a contract version and problem_type; do not send that internal envelope as if it were the public request schema.
{
"problem": { "employees": [], "shifts": [] },
"solver": {},
"options": { "engine": "benders_dw" }
}This empty shape explains the fields and will not solve a production problem. Populate the required records from the selected manifest before submitting.
Use a generated client in production
The curl examples are for understanding the HTTP boundary. Production integrations should pin a generated SDK to the deployed contract and keep authentication and error handling at that boundary.
Do not copy request models between applications or infer an API from an example response. Treat the deployment’s versioned OpenAPI and generated client as the integration reference.