GPU Render API for software

Canonical machine contract

Public API V1 uses https://farpy.com/v1. Render requests authenticate with Authorization: Bearer and a FARPY API key.

• Capabilities
• Pricing
• Limits
• OpenAPI 3.1.0

What GPU access means here

This is not unrestricted shell access, a generic CUDA rental, or an arbitrary container service. The current public lane exposes controlled GPU-backed Blender Cycles rendering.

The API is designed for callers that need a low-decision execution surface: discover support, determine price and limits, upload validated work, observe status, and retrieve the result.

Machine-readable capability discovery is authoritative. A caller should inspect GET /v1/capabilities rather than assume a renderer, software version, queue condition, or cancellation rule.

Operational contract

Public API V1 uses the base URL https://farpy.com/v1. Render routes authenticate with Authorization: Bearer followed by a FARPY API key.

GET /v1/pricing exposes the canonical public price. GET /v1/limits exposes current upload, request, and frame boundaries. GET /v1/openapi.json provides the OpenAPI 3.1.0 contract.

The public service rate limit is 60 requests per minute per client plus burst capacity. HTTP 429 responses provide retry guidance rather than silently dropping requests.

The maximum upload size is 100 MiB. HTTP 413 communicates that a payload is too large before it can become executable work.

Reliable software behavior

Idempotency-Key and X-Farpy-Request-Fingerprint support deliberate retry behavior around render creation and submission.

Structured errors expose code, message, retryable, suggested_action, and request_id. Software can separate permanent input failures from temporary conditions that may be retried.

Terminal states include completed, failed, and cancelled. Signed terminal events are render.completed, render.failed, and render.cancelled.

When a terminal webhook arrives, software should confirm canonical job status before performing irreversible downstream actions.

Delivery and trust surfaces

Completed work exposes download, receipt, and proof routes. These surfaces connect the delivered artifact to the authenticated workspace and canonical job record.

The receipt records the economic result. The proof surface records execution evidence appropriate to the public lane without exposing private node topology.

FARPY currently provides a constrained rendering API rather than every possible GPU workload. Broader GPU, encoding, inference, and batch-compute lanes remain separate future product work until individually qualified.

Implementation paths

Use the API quickstart for the granular request flow, the agent rendering guidefor low-decision automation, and thedeveloper reference for the complete endpoint contract.

Structured error handling is documented in theerror recovery guide. Signed terminal delivery is documented in the webhook guide.

GPU API operating summary

FARPY currently provides controlled GPU-backed Blender Cycles execution. It is not unrestricted GPU shell access, arbitrary CUDA execution, a generic container runtime, or a promise that any GPU workload can be submitted. Software should treat the machine-readable capability response as the live source of truth.

Read /v1/capabilities, /v1/pricing, /v1/limits, and /v1/openapi.json before creating work. The current price is $0.01 per completed Blender Cycles frame. Requests support frames 1 to 10,000, uploads up to 100 MiB, and 60 requests per minute plus burst capacity.

The API exposes explicit upload, submission, status, cancellation, download, receipt, and proof operations. Signed terminal webhooks report completed, failed, and cancelled jobs. Idempotency controls support safe retries, while structured errors tell callers whether a failure is retryable and what action should be taken next.

Frequently asked questions

Is this a general GPU rental API?

No. The current public GPU-backed lane is a controlled Blender Cycles rendering API rather than unrestricted shell or container access.

How does software discover current GPU capability?

Call GET /v1/capabilities and treat its machine-readable response as authoritative.

How are failures represented?

Errors expose code, message, retryable, suggested_action, and request_id fields.

Does the API support webhooks?

Yes. Signed terminal events cover completed, failed, and cancelled render jobs.

What verification records are available?

Completed jobs expose artifact download information, receipts, and proof records.