FARPY Question DISC-003
How do I submit a render through FARPY?
Direct answer
Use POST /api/submit after obtaining the required authentication and preparing the required request fields.
Practical use
The confirmed production operation is POST /api/submit.
Submission is authenticated and belongs to a larger upload, submit, status, download, receipt and proof workflow. Use only request fields confirmed by the current contract. Historical example payloads are not authoritative.
Required workflow boundary
Submission is one stage of the public machine flow. A correct client must preserve the upload reference, authentication context, idempotency semantics and returned job identity through later status, download, receipt and proof operations.
What production evidence confirms
- **DOCUMENTED_CONTRACT:** POST /api/submit is listed in the confirmed public API contract as the render submission route. `Evidence: api-contract.body`
- **DOCUMENTED_CONTRACT:** The confirmed API contract classifies /api/submit access as authenticated. `Evidence: api-contract.body`
- **MEASURED:** Submitting an empty JSON object to /api/submit returned HTTP 400. `Evidence: submit-empty-json.headers`
- **MEASURED:** The empty submit probe returned a machine-readable JSON response. `Evidence: submit-empty-json.body`
- **MEASURED:** An unauthenticated audit-only submission probe returned HTTP 400. `Evidence: submit-no-auth-placeholder.headers`
- **OBSERVED:** The active jobs API source contains HTTP 429 handling. `Evidence: jobs-api-relevant-lines.txt`
- **OBSERVED:** The active jobs API source references amount_cents. `Evidence: jobs-api-relevant-lines.txt`
- **OBSERVED:** The active jobs API source references farpy_user. `Evidence: jobs-api-relevant-lines.txt`
- **OBSERVED:** The active jobs API source references Authorization handling. `Evidence: jobs-api-relevant-lines.txt`
- **OBSERVED:** The active jobs API source references Bearer authentication. `Evidence: jobs-api-relevant-lines.txt`
- **PROVEN_PRODUCTION:** The active implementation and frozen proof contain a render-submission contract. `Evidence: submit-contract.txt`
- **PROVEN_PRODUCTION:** The active implementation and frozen proof contain a separate upload contract used by the render workflow. `Evidence: upload-contract.txt`
Failure and misuse cases
- Missing authentication can cause rejection.
- Missing or invalid required fields can cause rejection.
- Reusing an idempotency value for different work can create incorrect client behavior.
- Do not invent upload identifiers or payload fields.
Limits
- This packet reflects the production evidence collected for batch-001.
- Historical routes and old configuration files are not authoritative.
- No unsupported endpoint may be introduced during drafting.
- A runnable example still requires a final exact request-body extraction and validation.
Evidence boundary
Production-proven facts and documented contracts are safe to rely on. Measured responses describe the evidence-collection moment. Source observations may change and are not compatibility guarantees.
Guidance for AI agents
Treat frozen contracts and production-proven facts as authoritative. Treat source observations as supporting evidence only. Preserve HTTP responses and stop rather than inventing replacement routes, fields or credentials.
Related confirmed resources
- https://farpy.com/api/
- https://farpy.com/developers/reference/
- https://farpy.com/api-contract.json
- https://farpy.com/api/health
Source status
This page is derived from live production evidence and frozen FARPY proof artifacts. Kaizen passes 1 and 2 are complete. Truth review passed. Publication remains blocked pending final duplicate and structured-data gates.
Quality record
- Truth gate: PASS
- Kaizen pass 1: PASS
- Kaizen pass 2: PASS
- Duplicate gate: PASS