Can't find what you need? Ask below, or email hello@qbitseed.com.
Ask a question
Matches keywords against the FAQ below — not an AI model, just a quick way to jump to the right answer.
Most “random” APIs — including other “quantum” ones — are a classical CSPRNG under the hood: a deterministic formula seeded from a starting value. It looks random, but if that seed is ever exposed or guessed, everything it ever produced is reconstructable. QbitSeed sources entropy from a live physical IBM Quantum QPU instead, and every batch ships with a cryptographically signed certificate you can verify yourself.
IBM Quantum's Heron QPU, accessed through IBM Quantum Cloud. This isn't a simulator in production — every certificate is tied to a real job ID from that hardware, and source in the response tells you exactly which run produced your bytes.
A monitored failover layer serves the request from a certified classical CSPRNG instead of blocking it. We label this honestly, every time — the response's source field says classical_failover, never ibm_quantum when it wasn't. Check source on every response rather than assuming a 200 implies quantum provenance.
GET /certificates/{id}/verify — public, no API key required. It independently re-checks the certificate's Ed25519 signature against its payload.
That the certificate's signature matches its payload under QbitSeed's current signing key — i.e. this specific certificate genuinely came from QbitSeed and hasn't been tampered with. It doesn't independently prove the underlying bits came from quantum hardware rather than the honest classical-failover path — that's what the certificate's source field records, signed as part of the same payload.
No. QbitSeed provides genuinely quantum-sourced randomness and a verifiable certificate of origin for each response, but we don't certify, audit, or warrant that your specific use satisfies any regulatory standard. You're responsible for determining whether the Service fits your compliance needs and for obtaining your own certifications.
Every reseed runs through NIST SP 800-22 statistical randomness checks (monobit and runs tests) inline, before that entropy is served to anyone.
Yes — 150 requests/month, no card required. It's hard-capped at that quota, since there's no payment method on file to bill overage against.
Paid tiers meter and bill overage automatically instead of hard-rejecting your requests, as long as your subscription is active and in good standing. If payment is failing (a past_due subscription), you keep your base quota but lose overage eligibility until it resolves — Free tier and any tier without an active subscription still hard-blocks at quota.
base64 (what the API returns natively) or hex, reformatted client-side from the same underlying bytes — not a separate capability on the backend.
No. We store a certificate recording the batch's source, bit count, and a SHA-256 digest of the payload — not the raw random bytes themselves. The certificate proves what was delivered without QbitSeed retaining a copy of it.
You are. Keys are shown exactly once at creation and stored on our end only as a one-way hash — we can verify a key but can't display or recover it again. Revoke a key immediately from the dashboard if you suspect it's been exposed.
Seven years, including after an account is closed — that's the compliance trail proving the provenance of the randomness we delivered, in case you need to support your own audit or regulatory review.
Sign up for a free account, then create a key from the dashboard's API Keys page. No approval process or waitlist.
Not yet, formally. The Service is provided on a best-effort basis and may be briefly unavailable for maintenance or upstream quantum-provider issues. In practice the entropy pool is kept topped up continuously and reseeds run in the background without blocking your request.
Yes — Python (pip install qbitseed) and JavaScript/TypeScript (npm install qbitseed), both MIT-licensed. See the API docs for full endpoint reference.