Security

Security and operational controls for document workflows in production.

Solid Relay is built to make document generation easier to control, observe, and reason about when PDFs are tied to customer experience, revenue workflows, or internal operations.

The product is built around authenticated access, explicit limits, expiring hosted URL outputs, and request visibility that makes document behavior easier to review in production.

  • Authenticated account access and API key execution
  • Expiring hosted URL outputs with signed temporary reads
  • Request, usage, and audit visibility for review

Approach

Designed to reduce operational risk around rendering, delivery, and hosted URL output.

The current product scope is centered on access control, expiring hosted URL outputs, request visibility, and operational limits that are explicit enough to reason about before rollout.

Current scope

If you need specific answers about deployment model, safeguards, or rollout requirements, contacthello@solidrelay.io.

Access

Authenticated access for account routes, render execution, and controlled key usage.

Account routes use bearer tokens. PDF and batch execution routes use X-API-Key, and API keys can be scoped with IP allowlists for more controlled use.

Account routesBearer token access for authenticated dashboard and account actions.
Render executionX-API-Key is required for single and batch render requests.
Production controlIP allowlists can be applied to API keys for tighter usage boundaries.
Output handling

Hosted URL outputs expire, and download access is temporary.

When you use URL output, the API returns a hosted file with an expiresAt value. Temporary read access is used when signing is available, and expired hosted URL outputs are cleaned up from storage.

  • URL output includes explicit expiry metadata
  • Signed read access is temporary rather than indefinite
Visibility

Request, usage, and audit visibility for operational review.

Teams can inspect request history, usage, and audit events. Audit visibility depends on the plan, and request outcomes remain available for debugging and support workflows.

  • Request history for render debugging and support
  • Audit retention varies by account tier

Operations

Operational safeguards are part of the product surface, not hidden implementation detail.

The current security posture is mostly about controllability: clear execution limits, expiring hosted URL outputs, and enough visibility to review how document workflows behave over time.

Before rollout

If the workflow is sensitive, high volume, or part of a larger rollout, use the contact page to review fit, handling expectations, and current product scope before adoption.

Execution controls

Limits set by plan are part of the product surface, not hidden implementation details.

Request size, output size, render timeout, request rate, concurrency, batch size, and webhook availability are enforced as part of the product surface.

Render boundsInput size, output size, and timeout ceilings stay explicit for each plan.
ThroughputRequest rate, concurrency, and batch size are enforced operationally.
Feature gatesWebhook availability and other batch behavior follow plan rules.
Batch retention

Batch outputs and manifests expire instead of living indefinitely.

Batch jobs track hosted URL outputs, manifest files, and expiry windows. Expired batch files and manifests are removed from storage by cleanup paths.

  • Batch files and manifests are tracked with expiry windows
  • Expired artifacts are removed from storage cleanup paths
Review path

Use a more careful rollout review when the workflow needs it.

The contact path exists for workflows that need a closer review of handling expectations, operational fit, and current product scope before production adoption.

  • Useful for higher volume or more sensitive workflows
  • Best path for rollout questions before production adoption