SaQura
SDKsMCP serverREST API

SaQura Crypto API · REST · v1

SaQura Crypto API

Introduction

The SaQura Crypto API is a hosted REST interface for post-quantum cryptography over HTTPS — no SDK, callable from any language. It runs the same SaQura engine (1.0.11) as the SDKs.

  • Base URL: https://crypto.saqura.de
  • Algorithms: AES-256-GCM, RSA-4096 (OAEP/PSS), PBKDF2-SHA512, PQC-KEM (FrodoKEM / Classic-McEliece / X25519+ML-KEM FIPS 203), PQC-Signaturen (ML-DSA FIPS 204 / SLH-DSA FIPS 205)
  • Privacy: content is processed in memory and not stored; plaintext/keys never appear in responses or logs.

Discover capabilities (no key): GET /v1/capabilities · GET /health

curl https://crypto.saqura.de/v1/capabilities

Authentication

All /v1 crypto endpoints require an API key in the Authorization header (Bearer, Stripe-style):

Authorization: Bearer sk_live_…
  • sk_live_… = production, sk_test_… = test.
  • Get a key at saqura.de/pricing (SaQura Crypto subscription).
  • Missing/invalid key → 401. Plan lacks the capability → 403.

Quickstart

AES-256-GCM

# Encrypt (key optional — omit and the API returns a fresh key)
curl -X POST https://crypto.saqura.de/v1/aes/encrypt \
  -H "Authorization: Bearer sk_live_…" \
  -H "Content-Type: application/json" \
  -d '{"plaintext":"hello"}'
# -> {"ciphertext":"…","key":"…"}

# Decrypt
curl -X POST https://crypto.saqura.de/v1/aes/decrypt \
  -H "Authorization: Bearer sk_live_…" \
  -H "Content-Type: application/json" \
  -d '{"ciphertext":"…","key":"…"}'
# -> {"plaintext":"hello"}

Endpoints

All paths are relative to https://crypto.saqura.de. JSON fields are camelCase.

Method & pathRequestResponsePlan
GET /v1/usage—{plan, period, used, includedPerMonth, remaining, rateLimitPerMinute, overage}All
POST /v1/aes/encrypt{plaintext, key?}{ciphertext, key}Standard
POST /v1/aes/decrypt{ciphertext, key}{plaintext}Standard
POST /v1/password/hash{password}{hash}Basic
POST /v1/password/verify{password, hash}{valid}Basic
POST /v1/rsa/keypair{}{publicKey, privateKey}Basic
POST /v1/rsa/encrypt{plaintext, publicKey}{ciphertext}Basic
POST /v1/rsa/decrypt{ciphertext, privateKey}{plaintext}Basic
POST /v1/rsa/sign{data, privateKey}{signature}Basic
POST /v1/rsa/verify{data, signature, publicKey}{valid}Basic
POST /v1/quantum/keypair{strength?, generation?}{publicKey, privateKey, strength, generation}Pro
POST /v1/quantum/encrypt{plaintext, publicKey}{ciphertext, encapsulatedSecret}Pro
POST /v1/quantum/decrypt{ciphertext, privateKey, encapsulatedSecret}{plaintext}Pro
POST /v1/quantum/sign/keypair{strength?, algorithm?}{publicKey, privateKey, strength, algorithm}Pro
POST /v1/quantum/sign{data, privateKey, algorithm?}{signature}Pro
POST /v1/quantum/verify{data, signature, publicKey, algorithm?}{valid}Pro

Your usage

GET /v1/usage returns your own API key's usage for the current month (plan, requests used, included allowance, remaining, limit, overage). Authenticated like every /v1 endpoint, but itself NOT billed — you only ever see your own figures.

# Your own usage for the current month (authenticated, NOT billed)
curl https://crypto.saqura.de/v1/usage \
  -H "Authorization: Bearer sk_live_…"
# -> {"plan":"Pro","period":"2026-06","used":1234,
#     "includedPerMonth":2000000,"remaining":1998766,
#     "rateLimitPerMinute":1200,"overage":{"requests":null,"per1000":1,"note":"…"}}

Post-quantum (KEM + signatures)

KEM encryption (Pro+). Generations: Gen4–7 (BSI profile) and Gen8 (X25519 + ML-KEM, FIPS 203). Decryption needs both ciphertext AND encapsulatedSecret.

# 1) key pair  (Gen4 default; Gen8 = X25519 + ML-KEM / FIPS 203)
curl -X POST https://crypto.saqura.de/v1/quantum/keypair \
  -H "Authorization: Bearer sk_live_…" -H "Content-Type: application/json" \
  -d '{"strength":"Highest","generation":"Gen8"}'
# -> {"publicKey":"…","privateKey":"…","strength":"Highest","generation":"Gen8"}

# 2) encrypt to the public key
curl -X POST https://crypto.saqura.de/v1/quantum/encrypt \
  -H "Authorization: Bearer sk_live_…" -H "Content-Type: application/json" \
  -d '{"plaintext":"secret","publicKey":"…"}'
# -> {"ciphertext":"…","encapsulatedSecret":"…"}

# 3) decrypt  (needs both ciphertext and encapsulatedSecret)
curl -X POST https://crypto.saqura.de/v1/quantum/decrypt \
  -H "Authorization: Bearer sk_live_…" -H "Content-Type: application/json" \
  -d '{"ciphertext":"…","privateKey":"…","encapsulatedSecret":"…"}'
# -> {"plaintext":"secret"}

Signatures (ML-DSA / SLH-DSA)

# ML-DSA (FIPS 204) — pass "SLH-DSA" for FIPS 205
curl -X POST https://crypto.saqura.de/v1/quantum/sign/keypair \
  -H "Authorization: Bearer sk_live_…" -H "Content-Type: application/json" \
  -d '{"strength":"Highest","algorithm":"ML-DSA"}'

curl -X POST https://crypto.saqura.de/v1/quantum/sign \
  -H "Authorization: Bearer sk_live_…" -H "Content-Type: application/json" \
  -d '{"data":"document","privateKey":"…","algorithm":"ML-DSA"}'
# -> {"signature":"…"}

curl -X POST https://crypto.saqura.de/v1/quantum/verify \
  -H "Authorization: Bearer sk_live_…" -H "Content-Type: application/json" \
  -d '{"data":"document","signature":"…","publicKey":"…","algorithm":"ML-DSA"}'
# -> {"valid":true}

Plans & quotas

Capabilities are unlocked per plan. There are two limits: a per-minute throughput limit (per API key, anonymous: per IP) and — on monthly plans — a monthly included request quota.

PlanCapabilitiesQuota (req/min)Included/mo
BasicRSA · Password30050.000
Standard+ AES600250.000
Pro+ Quantum (KEM · ML-DSA · SLH-DSA)12002M
Scale+ Quantum (high volume)600010M
Enterpriseall12000custom
no/invalid key— (401)60—

On monthly plans, usage above the monthly included quota is billed by usage: 1 € per 1,000 requests (or the equivalent in the selected currency). Annual plans have no usage-based overage. Values are starting quotas and may be tuned.

Note: compute-intensive key generation (RSA / post-quantum keypair, password hashing) is additionally concurrency-limited to keep the service stable under load. During spikes such a request may therefore return 429 (Retry-After header) even within your per-minute quota — wait briefly and retry with exponential backoff.

Errors

Errors follow the Problem Details format (RFC 7807):

  • 400 — invalid input (e.g. "Invalid base64 input."). The payload is never echoed back.
  • 401 — missing/invalid key.
  • 403 — plan does not include the capability.
  • 429 — quota exceeded (Retry-After header).

Questions? contact form. Never include keys/plaintext in tickets.