Use reliable patterns for validate, compile, render, download, and retry behavior.

Overview

Use reliable patterns for validate, compile, render, download, and retry behavior. API clients must be tenant-aware, permission-aware, and capable of handling both JSON and binary responses.

Key points

• Cache stable template UUIDs but handle replacement deliberately.
• Compile composite templates during publishing rather than the user request.
• Stream binary responses directly to files.
• Decode metadata base64 only after checking success.
• Do not retry structural template failures.
• Use an orchestration API rather than exposing Render credentials to WordPress.

Recommended procedure

1. Send authentication and instance headers.
2. Validate the request body before transmission.
3. Inspect HTTP status, content type, and structured errors.
4. Log non-sensitive identifiers needed to reproduce failures.

Client requirements

• Check the HTTP status before processing the body.
• Check Content-Type before deciding whether the response is JSON, DOCX, or PDF.
• Do not log authentication tokens or complete client document data.
• Preserve the instance context through every Feradel service-to-service call.
• Treat validation and compilation errors as input or template defects rather than transient network failures.

Troubleshooting

A client treats an error as a file

Check HTTP status and Content-Type before writing the response body to disk.

The same request works in another tenant

Compare instance, owner, token permissions, and object UUIDs.

A route returns an unexpected envelope

The current controllers are not fully standardized; handle HTTP status and documented fields defensively.

Related documentation

• DOCX-to-PDF and XML API Reference
• PDF Document and PDF Form API
• DOCX Rendering API

Documentation source: feradelinc/feradel.render.api, reviewed against repository revision b2c3a710. Verify behavior against the deployed release before publishing exact routes, limits, or version requirements.