Free LLM API Demo

A transparent API lifecycle you can inspect

This demonstration is designed to show the mechanics around an API rather than pretend to offer generative intelligence. Registration creates a cryptographically random Anna key. A keyed hash and short prefix are stored in private JSON Lines files outside the public web root; plaintext keys are not stored. When a valid active key calls the endpoint, the server returns a small type-specific sample that is deliberately labelled synthetic.

1. Register
   Submit limited contact details, a demo type and explicit consent.
2. Save the key
   The plaintext credential is shown once in the current browser session.
3. Test responses
   Use the workbench or an example request and handle real HTTP status codes.

What validation does—and does not—mean

The form rejects malformed, reserved, disposable and obvious placeholder email patterns, checks that the email domain publishes an MX or A record, and applies E.164-style and basic country-length checks to the phone number. It also rejects common repeated, sequential and dummy patterns. These are plausibility controls only. Without an OTP or verification email, they cannot prove that an address or phone number belongs to the visitor.

Privacy and retention

Registration records include the cleaned fields you submit, API type, consent version, timestamps, key prefix and hash, status, a salted hash of the requesting IP and a truncated user-agent. Usage logs exclude prompts and plaintext secrets. Operational guidance sets a default review-and-delete target of 90 days for usage logs and 180 days after revocation or inactivity for registrations, subject to legal and abuse-prevention needs. See the privacy policy and use the contact page for a privacy request.

Generate and manage a demo key

The key remains masked until registration succeeds. Generate and Copy open the same registration gate when no active key exists. Regeneration and revocation require both the current plaintext key and the browser session that created it.

Credential handling checklist

• Send the key through the Authorization: Bearer header, not a URL query string.
• Do not commit it to source control, expose it in public client bundles or paste it into issue trackers.
• Regenerate after suspected exposure and update the secret in your application immediately.
• Revoke a key that is no longer required. Revoked requests receive an HTTP 403 response.

Quick Start

The examples below call the same internal endpoint used by the browser tester. Replace the placeholder after creating a key. Requests are JSON, use POST and include a prompt of 1–500 characters. The prompt influences only validation and sample metadata; no model processes it, and it is not written to usage logs.

Expected success envelope

A valid call receives HTTP 200 and a body containing status=success, demo=true, code=200, a unique request ID, UTC timestamp, API type, explanatory message and a compact synthetic data object. Integrations should inspect the HTTP status as well as the JSON body.

API Tester

This workbench sends a real same-origin request to /api/demo-call.php. Generate a key first; the response panel shows the actual status and JSON returned by PHP.

Generate a key, then send a request. The actual HTTP status and JSON response will appear here.

Documentation

Endpoint

POST /api/demo-call.php accepts same-origin requests with JSON or standard form data. Supply the key in Authorization: Bearer anna_demo_…. Cross-origin access is not enabled.

HTTP status contract

Security model and limits

Keys are generated with the operating system cryptographic random source and stored only as HMAC-SHA-256 hashes using a private pepper. JSON Lines updates use exclusive file locks and restrictive permissions. This design suits a modest shared-hosting demo, not high-throughput infrastructure. It has no database, distributed lock, model backend, uptime guarantee or external credential brokerage.