Docs Home
Find the right start path before you integrate
Solid Relay provides one API for single PDF renders, accepted jobs, batch rendering, template based workflows, and signed in account and billing flows.
How to use this page
- Scan the capability map to confirm the API surface matches your task.
- Confirm the auth split before you wire credentials into code.
- Choose one start path: quickstart, concepts, or API reference.
Best first validation
Send one render request, then confirm whether it completed now or was accepted for follow up.
POST/v1/pdf
Auth split
Rendering routes use the render API key header. Account routes use hybrid bearer auth: access token in memory, refresh cookie on the wire.
Render outcomes
A valid first render can return output now or accepted work with a job ID to follow.
Capability Map
Understand the public surface in four capability groups
Use this map to decide whether you are validating one render path, planning accepted or batch follow up, or wiring the account surfaces around those workflows.
01
Render one PDF
Use the single render route for exactly one input source: HTML, URL, or a saved template.
POST/v1/pdf
02
Follow accepted single renders
When work is accepted instead of returned immediately, use job status and file follow up routes to complete the flow.
GET/v1/pdf/jobs/:id
03
Queue and retrieve batches
Batch rendering accepts many items, then gives you status, zip download, item download, and cancellation follow up.
POST/v1/pdf/batch
04
Manage reusable resources and account assets
Use signed in account routes for API keys, templates, usage, subscription state, invoices, and other account level workflows.
Auth Split
Keep rendering credentials separate from signed in account credentials
This is the fastest way to avoid early integration mistakes. If you identify the route family first, the correct credential is usually obvious.
Rendering routes
Use API keys for create, status, download, and batch follow up
Single render, render job status, render job file download, batch create, batch status, batch zip, batch item download, and batch cancellation all use the render API key header.
Read auth modelsAccount routes
Use hybrid bearer auth for identity and account owned resources
Authentication, profile, API key management, templates, usage, billing, invoices, and other account surfaces operate in signed in user context with an in memory bearer access token that is refreshed by an httpOnly cookie.
Open authentication referenceSmall public exception set
Some confirmation and disable flows use signed tokens instead
Public signed link flows exist for a few scoped actions, including auto overage disable and GDPR export confirmation or download. Those routes do not use normal render or bearer credentials.
See billing and account follow up routesStart Paths
Choose the next page by the question you need answered first
These three routes are the intended entry points for evaluators and first time integrators. Pick one, finish that pass, then branch only when your next question changes.
Need one working request fast?
Start with quickstart
Use one render key, one minimal request, and one success check that handles both immediate and accepted outcomes.
Need the mental model first?
Read the concepts layer
Use the concepts hub for auth models, execution behavior, idempotency, and job lifecycle before deep implementation.
Need exact contracts?
Open the API reference
Use the reference hub when you already know the capability you need and want the canonical route family fast.