P
creatorr.tech

creatorr.tech API.

JSON over HTTPS, bearer auth, the same API the app uses. Every server tool follows the same flow: presigned upload → enqueue job → poll status → presigned download.

Public access (issuable API keys, rate limits, signed webhooks) is on the roadmap. Until then, these endpoints back the web app.
# 1) Register / sign in to get a JWT.
curl -s -X POST https://api.creatorr.tech/v1/auth/login \
  -H 'Content-Type: application/json' \
  -d '{"email":"you@example.com","password":"********"}' \
  | jq -r '.data.token' > token.txt

# 2) Mint a presigned upload URL.
curl -s -X POST https://api.creatorr.tech/v1/files \
  -H "Authorization: Bearer $(cat token.txt)" \
  -H 'Content-Type: application/json' \
  -d '{"name":"input.pdf","mime_type":"application/pdf","size_bytes":1234567}' \
  > presigned.json

# 3) Upload bytes directly to R2. The API never proxies file content.
curl -s -X PUT \
  "$(jq -r '.data.upload_url' presigned.json)" \
  -H 'Content-Type: application/pdf' \
  --data-binary @input.pdf

# 4) Enqueue a job.
curl -s -X POST https://api.creatorr.tech/v1/jobs \
  -H "Authorization: Bearer $(cat token.txt)" \
  -H 'Content-Type: application/json' \
  -d '{"tool":"compress_heavy","input_file_id":"'$(jq -r '.data.file_id' presigned.json)'","params":{"quality":70}}'

Request and response shape

Successful responses are wrapped in { data: ... }. Errors are wrapped in { error: { code, message, request_id } }.Treat code as the contract; message may change.

# Success
{ "data": { "id": "fil_01J...", "name": "input.pdf", ... } }

# Error
{ "error": { "code": "validation", "message": "size_bytes must be > 0", "request_id": "req_01J..." } }

Bearer auth: Authorization: Bearer <jwt>. Tokens are session-bound; signing out from one device revokes the JWT everywhere. Idempotency: Idempotency-Key header on POST /v1/jobs.

Common errors

  • unauthorized — missing or rejected token.
  • invalid_credentials — wrong email or password.
  • email_taken — email already registered.
  • validation — request body failed validation.
  • too_large — file exceeds the 10GB upload cap.
  • unknown_tool — server tool slug not recognized.
  • not_found — file or job missing or not yours.

Auth

POST/v1/auth/register

Create a user account.

Body
  • emailstring
  • passwordstring ≥ 8
  • namestring (optional)
Response
201: { token, expires_at, user }
POST/v1/auth/login

Sign in with email and password.

Body
  • emailstring
  • passwordstring
Response
200: { token, expires_at, user }
401: { error: { code: "invalid_credentials" } }
POST/v1/auth/logoutauthed

Revoke the current session.

Response
204
GET/v1/meauthed

Return the current user.

Response
200: { id, email, name, plan }

Files

POST/v1/filesauthed

Mint a presigned upload URL for direct-to-R2 PUT.

Body
  • namestring
  • mime_typestring
  • size_bytesinteger (≤ 10GB)
Response
201: { file_id, upload_url, expires_at, method, headers }
GET/v1/files/{id}authed

Return file metadata + a presigned GET URL.

Response
200: { id, name, size_bytes, mime_type, storage_tier, expires_at, created_at, download_url }
DELETE/v1/files/{id}authed

Soft-delete a file.

Response
204

Jobs

POST/v1/jobsauthed

Enqueue a server-side tool against an uploaded file.

Body
  • tool"compress_heavy" | "office_to_pdf" | "ocr"
  • input_file_idstring (from POST /v1/files)
  • paramsobject (tool-specific)
Response
201: { id, tool, status, progress, input_file_id, params }
GET/v1/jobs/{id}authed

Poll job status until terminal (succeeded | failed | canceled).

Response
200: { id, tool, status, progress, output_file_id?, error_code?, error_message? }

Billing

POST/v1/billing/checkoutauthed

Stripe Checkout session for a Pro subscription.

Body
  • cycle"monthly" | "yearly"
Response
200: { url }
POST/v1/billing/portalauthed

Stripe Customer Portal session for an existing subscriber.

Response
200: { url }
POST/v1/billing/webhookwebhook

Stripe webhook receiver. Verifies signature; updates user plan.

Response
200: { received: true }

Public API status

The endpoints above are real and stable, but bearer tokens are issued per-user via login — there's no public API key flow yet. Webhooks (other than Stripe billing) are not exposed. Public API keys, signed customer webhooks, and per-key rate limits land with the developer platform release.

If you want early access, drop a line.