What these documents provide
These pages describe a proposed processing API design. They are implementation references, not instructions for calling a hosted ProcessAPI.com service. There is no API-key signup, live request console, SDK package, or browser-based processing endpoint.
The example separates a process definition, an input manifest, a run, and a result manifest. That structure gives a team concrete objects to discuss before selecting persistence, dispatch, worker, or model-serving technologies.
Follow the contract from input to result
Begin with the quickstart to inspect a request and a status representation. Then review the job lifecycle to agree on state transitions and failure behavior. Finish with batch manifests to define what a complete delivery must account for.
All examples use the same process name and manifest identity so the relationship between files is easy to follow. The logical input and output paths stand for locations your own implementation would manage, not downloadable business documents on this website.
Reference files
Download the job request, input manifest, run status, or result manifest. The example notes summarize their relationship.
Adapt the patterns to your authorization boundary, process versions, data policy, and partial-success rules. Test both successful and interrupted cases before treating any design choice as an operational guarantee.
Go deeper into the architecture
The business process API playbook discusses identity, authorization, versioning, and errors. The webhook reliability playbook examines repeated delivery and external effects. The self-hosted guide connects the interface to the responsibility of operating it.