Guide

Security & data protection

Keep your API key safe, secure your integration, and how api2convert protects your data.

This guide has two parts: how to secure your integration with the API, and how api2convert protects the data you send us. For the mechanics of authenticating a request, see Authentication & API keys.

Securing your integration

Keep your API key secret

Your API key authenticates every request and spends your credits, so treat it like a password. Keep it on your server — never embed it in browser JavaScript, mobile apps, or public repositories. For client-side or native apps, proxy requests through your own backend and hand out per-job tokens instead of the key.

Use scoped job tokens

Each job has its own token. A token grants access to that single job and can be sent in the x-oc-token header in place of your API key — ideal for giving a client temporary, least-privilege access to one job's status and outputs without exposing your key.

Rotate a key if it leaks

Keys are self-service: you can hold more than one and add or remove them at any time from your account's API keys page. There is no single "regenerate" button — to rotate a compromised key, create a new one, move your integration over to it, then delete the old key. Deleting a key takes effect immediately.

Always use HTTPS

Call the API over HTTPS so your key and payloads are encrypted in transit. Plain-HTTP requests are rejected with 426 Upgrade Required — switch the scheme to https:// and retry.

Verify webhook callbacks

Webhook payloads are not cryptographically signed, and the sender does not verify your endpoint's TLS certificate. Don't act on a callback body blindly: re-fetch the job with your own API key (GET /v2/jobs/{id}) to confirm it's really yours before doing anything with it. Make your handler idempotent — see Webhooks & callbacks.

Protect sensitive files

You control how long your data lives and who can reach it:

  • Password-protect a result with a download_password; downloading it then requires the x-oc-download-password header.
  • Delete a result early — DELETE /v2/jobs/{id}/output/{output-id} disables a single processed file so its download link stops working immediately; DELETE /v2/jobs/{id} removes the whole job. (Files are purged automatically when the job expires, but this revokes access right away.)
  • Set "delete_after_use": true on an input — at job creation, or later with PATCH /v2/jobs/{id}/input/{input-id} — to have the uploaded source file deleted from our servers when the job finishes (whether it completes or fails).
  • Download URLs expire automatically after 24 hours — see Output & cloud storage.
"input": [{
  "type": "remote",
  "source": "https://your-app.example.com/private/report.docx",
  "parameters": { "delete_after_use": true }
}]
When you export results to your own cloud storage, the provider credentials you send are secrets — scope them to a single bucket/folder and rotate them like any other credential.

Handle limits gracefully

Hitting your contract's concurrency cap returns 429 Too Many Requests (back off and retry with exponential backoff); exhausting your quota returns 402 Payment Required. Prefer webhooks over tight polling loops. See Rate limits & contracts.

How api2convert protects your data

On our side, your files and credentials are protected at several layers:

  • Encryption in transit — all API traffic is served over TLS.
  • Encryption at rest — our servers use full-disk encryption, backups are encrypted, and any cloud-storage credentials you provide are additionally encrypted at the application layer before they are stored.
  • Password protection — download passwords are stored only as salted hashes and verified in constant time; we never keep the plaintext.
  • Data lifecycle — download links expire after 24 hours, and delete_after_use lets you remove source files as soon as a job is done.
  • Abuse protection — traffic passes through DDoS mitigation and rate limiting at the edge.
  • Isolated infrastructure — processing systems and datastores run on a private network and are not reachable from the public internet.
  • Vulnerability management — our dependencies are continuously screened against known security advisories.
Encryption at rest protects stored data on our infrastructure (for example, against physical disk access). It is not a substitute for the safeguards above that are yours to apply — keeping your key secret, using HTTPS, and verifying callbacks.

Reporting a security issue

Found a vulnerability? Please report it responsibly to time2help@api2convert.com and give us a reasonable window to investigate and fix it before any public disclosure.