Add editable exports to a document product
Let users send a PDF through your existing application and receive an editable PPTX without exposing your API key to the client.
REST API → editable PowerPoint workflow
Automate PDF-to-PPTX conversion with a REST API
Create authenticated conversion tasks from uploaded PDFs or public URLs, select pages, poll status or receive a signed callback, and download the resulting PPTX from a temporary signed URL.
Start with 10 one-time pages. No credit card required.
What this workflow does
From a flat visual reference to a working deck
Reslide exposes the same credit balance and conversion service used by the web workspace through a Bearer-key REST API. Every response uses the envelope {code, message, data}; code is 0 on success and otherwise mirrors the HTTP status.
The API is asynchronous because conversion is a task rather than a request that holds the connection open. Create a task, store its task_id, and either poll the status endpoint or supply an HTTPS callback_url. Treat download URLs and uploads as temporary: both are documented with a 24-hour lifetime.
Step by step
A reviewable conversion workflow
The source stays important after conversion: use it to verify the new, editable representation before sharing or automating downstream work.
- 1
Create and protect an API key
Sign in at /keys, create a tpx_live_ key, store it in a secret manager, and send it as Authorization: Bearer on every /v1 request. Do not embed it in browser code or documentation.
- 2
Provide exactly one input form
Upload a local PDF and use upload_id, or supply pdf_url. Image-list tasks instead accept ordered upload_ids or image_urls. PDF tasks may add 1-based pages to convert a subset.
- 3
Create the task idempotently
POST /v1/tasks with operation pdf_to_pptx or images_to_pptx. Send your own unique Idempotency-Key so a retry returns the existing task instead of reserving credits twice.
- 4
Observe the terminal result
Poll GET /v1/tasks/{task_id}, or verify the HMAC-SHA256 X-Tosea-Signature on an at-least-once callback. On success, download and persist result.pptx_url before it expires.
Create a task with a public PDF URLcURL
curl -X POST https://pptx-api.tosea.ai/v1/tasks \
-H "Authorization: Bearer $TOSEA_PPTX_API_KEY" \
-H "Content-Type: application/json" \
-H "Idempotency-Key: conversion-123" \
-d '{
"operation": "pdf_to_pptx",
"input": {
"pdf_url": "https://example.com/deck.pdf",
"pages": [1, 2, 5],
"title": "Editable review deck"
},
"callback_url": "https://example.com/webhooks/reslide"
}'Good fit
When this path is useful
Process a controlled conversion queue
Use task listing, status filters, plan concurrency, idempotency keys, and webhooks to coordinate server-side work.
Give an automation agent a bounded tool
Expose a wrapper that accepts explicit files or URLs, creates one task, waits for a terminal state, and saves the result without granting unrelated account access.
Before you convert
Prepare the source
- Call GET /v1/credits and GET /v1/limits before submitting a large job.
- Keep API keys and webhook secrets on a trusted server, never in frontend bundles.
- Use a stable application identifier as the Idempotency-Key for retries.
- Make webhook processing idempotent by task_id and keep polling as a fallback.
Service rules
Current public contract
- 1 credit is reserved for each page and settles on a successful task.
- Failed or canceled tasks have zero net billable task credits; reservations are reconciled against their original credit pools under those pools' lifecycle rules.
- The current defaults are 100 pages per task and 100MB per upload.
- API users can query GET /v1/limits instead of relying on hard-coded limits.
Honest boundaries
What to inspect after conversion
Reslide reconstructs from the submitted visual source. It does not claim to recover information, behavior, or authoring structure that the source no longer contains.
Limits are part of the live account contract
The current defaults are 100 pages per task and 100MB per upload, while concurrent tasks depend on plan. Query GET /v1/limits instead of hard-coding assumptions.
Remote inputs must be retrievable
Use uploads for local or private files. URL inputs are for public sources the backend can fetch; do not place credentials in URLs.
Callbacks can be delivered more than once
Webhook delivery is at-least-once with retries. Verify the raw-body signature and deduplicate by task_id before applying side effects.
FAQ
Common questions about this workflow
Which endpoints are public API endpoints?
The documented Bearer-key API includes POST /v1/uploads; POST and GET /v1/tasks; GET /v1/tasks/{task_id}; POST /v1/tasks/{task_id}/cancel; GET /v1/credits; GET /v1/usage; and GET /v1/limits. Use /openapi.json as the machine-readable source of truth.
How does API billing work?
One credit equals one converted page. Failed or canceled tasks have zero net billable task credits; reservations are reconciled against their original paid and bonus pools subject to those pools' lifecycle rules. The web workspace and API share the account balance.
How should my integration handle rate limits?
A 429 response includes Retry-After. The current per-key implementation uses a 10 request/second rate with a burst of 30, and task concurrency also depends on plan. Back off and query the task rather than creating a duplicate.
How do I verify a conversion webhook?
Compute HMAC-SHA256 over the raw request body with the webhook secret shown in /keys, prefix the hexadecimal digest with sha256=, and compare it safely with X-Tosea-Signature. Return a 2xx promptly and deduplicate by task_id.
Continue exploring
Related conversion workflows
Start with the source you already have
Convert in the workspace, or use the documented REST API for a repeatable server-side workflow. Review the PPTX before it becomes a final deliverable.