Privacy

Vote MCP is an API service for signed polling and voting. This page states what the hosted service collects, what it encrypts, what remains operational metadata, and when stored records become eligible for deletion.

What the service stores

Payload content is application-encrypted before database storage. This covers poll definitions, derived answer schemas, vote responses, feedback text and metadata, feedback evidence, and idempotency replay response bodies.

This provides database-provider confidentiality. It is not end-to-end encryption: the server decrypts payload content in application memory to validate requests, enforce poll rules, return authorized responses, and perform normal service operations.

Clients choose the poll, vote, and feedback content they submit. Off-server identity mappings and private signing keys are not managed by the hosted service.

Operational metadata

Operational metadata needed for lookup, replay, audit, retention, and protocol verification remains plaintext by design. This includes identifiers, hashes, fingerprints, public keys, signatures, statuses, timestamps, route and method fields, idempotency lookup fields, retention fields, counters, and other protocol metadata.

Operational logs and alerts

The service also keeps operational logs and alerts needed to run the service, debug failures, correlate client-visible errors by request ID, monitor availability, audit lifecycle transitions, and investigate abuse or malformed traffic.

These records may include request metadata such as time, method, host, path, status, duration, request ID, edge client address, router or service names, lifecycle events, synthetic check results, and error details. The API does not use query strings for poll, vote, or feedback content.

Cookies and analytics

The hosted API and public informational pages do not use advertising cookies or third-party analytics. Normal public and API responses do not set browser cookies. Framework cookies may exist for operator-only or framework-provided surfaces.

Access and service providers

Operational data is available to service operators and the infrastructure providers needed to run the hosted service. Database-stored payload content is application-encrypted before storage, but the server can decrypt it during normal operation. Compact operational alerts may be sent through the configured reporter path.

The hosted service depends on infrastructure providers for hosting, networking, TLS, database storage, and operational alert delivery. These providers may process operational metadata needed to deliver and run the service.

Retention

Runtime database retention is published in the top-level data_retention object returned by GET / and GET /.well-known/api-catalog. These lists render that same contract for the current deployment. Other operational practices described here reflect the current hosted deployment and may be updated as the service matures.

Current deployment: demo. Poll records can move through lifecycle deadlines before their final retention window applies. Cleanup windows are not exact erasure times: until cleanup physically deletes a record, it is still stored data. Cleanup is eventual; actual deletion happens on a successful cleanup run and may be later if cleanup is delayed, bounded by batch limits, or not running. After cleanup deletes a poll, lookup returns 404 poll_not_found, the same response as a poll ID that never existed.

Poll lifecycle deadlines

Cleanup windows

Logs, backups, and alert history

Database record retention is described above. Operational logs, provider logs, backups, and alert history are separate operational systems and may follow different retention schedules. They are kept as needed to operate, secure, debug, and audit the service.

Privacy requests

A privacy contact and request process will be published in due course. Requests may require enough information to identify the relevant records, such as poll IDs, request IDs, or other client-held references.

Last updated: 2026-06-16

Build date: 2026-06-29