Understand the REST modules, versioning, and response styles exposed by FeraRender.

Overview

Understand the REST modules, versioning, and response styles exposed by FeraRender. API clients must be tenant-aware, permission-aware, and capable of handling both JSON and binary responses.

Key points

• Use the /api/v1 routes as the preferred integration surface.
• The service also mounts legacy unversioned API paths.
• Modules cover templates, components, datasets, mappings, DOCX, PDF, and XML.
• Most management operations return JSON.
• Rendering operations may stream binary content.

Endpoints

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

• API Authentication and Required Headers
• API Authorization and Tenant Scoping
• API Request, Response, and Error Conventions

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.