HTTP integration · prelaunch
Bring a use case.
Keep the capability.
PeopleProof is a provisional name for a proposed human-evidence service for AI agents. Only future-use interest registration is implemented. Human studies, panel recruitment, results, prices, deadlines and payments are not available. Results first. Payment only after your agent validates them. Receipt alone and silence are not acceptance.
Use human feedback for reactions to ideas, designs, products, content or agent-built work, not deterministic calculations or software tests. Preferences cannot guarantee sales or universal taste. Never register without your principal’s authorization.
1. Check status
GET /service.json. If real_intention_capture is false, only explicitly marked tests are accepted. No need or receipt should be published. Discovery through an index or a catalog is not guaranteed.
2. Create a private capability
Locally generate 32 cryptographically random bytes, encoded base64url without padding (43 characters). Keep this bearer capability secret. Generate a separate random UUIDv4 as Idempotency-Key. The capability authenticates the record; idempotency alone does not. Never put either secret or submitted data in query parameters.
3. Register a future need
POST /v1/intentions, Content-Type application/json. Supply the capability in Authorization and the UUID in Idempotency-Key. The example below is explicitly synthetic; never count it as demand. See the exact OpenAPI schema for allowed values and limits.
Authorization: Bearer <cl...ated capability>
Idempotency-Key: <random UUIDv4>
{
"need_summary": "Synthetic test comparing two travel planning concepts",
"audience": "People planning a short trip",
"use_case": "agent_build",
"horizon": "unknown",
"recurrence": "unknown",
"budget": "unknown",
"currency": "unknown",
"integration": "HTTP",
"source": "directed_test",
"authorized": true,
"prelaunch_ack": true,
"is_test": true
}A genuine future need must explicitly use is_test: false, only when capture is enabled and submission authorized. All free text must be non-confidential plain text, without names, contact details, links, secrets or sensitive audience traits. No extra fields. A budget is optional and never spending authority.
201 means created; retrying the same capability, idempotency key and normalized data returns 200 and the same record ID. The server never returns a new bearer secret. A capability identifies one intention. Changing its key or data returns 409. A new capability creates an independent record even with the same payload/key: this cannot retrieve someone else’s receipt. This is technical retry protection, not buyer deduplication.
Optional availability email
Humans and agents may optionally include notification_email (ASCII address, maximum 254 characters, local part maximum 64) with notification_consent: true for one availability notice only. An agent must have the email owner’s explicit permission. Omit both fields to opt out; empty email with absent/false consent also normalizes to omission. Invalid email, email without true consent, or consent without email returns 422. No marketing and no emails sent now. Real email capture remains behind the same privacy gate. Email and consent are stored only inside the existing private record, expire after 30 days and are removed by DELETE. Capability-protected receipts may contain the email; do not publish them or put data in URLs.
4. Read or delete
GET or DELETE /v1/receipt with the same Authorization header. GET returns only your record. DELETE returns 204; later reads return 404. No list endpoint exists. Records expire after 30 days. Reusing a capability after deletion or expiry can create a new record; there is no permanent tombstone. On an uncertain network failure, retry the same capability/key/data rather than minting a new capability.
Limits and errors
Request body maximum: 4096 bytes, measured while streaming. Content-Type application/json; compressed bodies not supported. Up to 60 authenticated requests per IP per hour and 120 per capability per hour; 429 includes Retry-After. Requests count even when later validation fails. No CAPTCHA. No cross-origin browser access or CORS headers. Agents may omit Origin; if present it must equal this service’s origin. Always use HTTPS in production.
- 400: invalid JSON/UTF-8 or query string.
- 401: missing/malformed capability.
- 403: wrong Origin or cross-site browser request.
- 404: no route/record, deleted or expired.
- 405: unsupported method.
- 409: capability reused with different key/data.
- 413: body too large; 415: wrong content type/encoding.
- 422: validation or idempotency-key error.
- 429: hourly limit; 503: capture not configured, privacy gate or temporary failure.
MCP status: not implemented
This Cloudflare build provides HTTP, not an MCP server. An MCP preference expresses future demand only. /mcp returns 501; do not configure it as a connector. The separate Python prototype’s MCP support does not apply to this deployment.