At a glance
nData is in public beta. The legal operator, jurisdiction, provider list and exact retention periods are pending confirmation. The table describes the current design; it is not a complete legal compliance statement.
| Data | Current handling |
|---|---|
| Account and identity | Name, email, authentication and recovery state, connected identity and MFA records, sessions, and account security events. |
| Workspace and API access | Workspace, memberships, roles, invitations, API-key metadata and revocation state, quotas and account history. |
| Job inputs and results | Public-post URL, prompt, output schema or template, transcription options, job status and timestamps, output or failure. Results are workspace-scoped. |
| Public-source cache | Public metadata, media, and prompt-independent transcript artifacts may be reused across workspaces for the same canonical URL. |
| Support | Category, message, reply email and optional contact details. Ticket storage is encrypted and durable. Tickets are retained indefinitely until the operator sets a policy. |
| Credits and billing | Reservations, settlement, usage and accounting history; billing or subscription metadata when billing is enabled. |
| Webhooks | Destination URL, encrypted signing secret and event payload, which can contain the job result. |
What the beta processes
Processing is for individual public posts on supported social platforms. Private or authenticated feeds, profiles, search pages and login-mediated access are outside the current contract. The source platform can change, remove or restrict a post, and a successful URL check does not guarantee retrieval.
The anonymous sample playground runs with static sample data. Submitting a signed-in portal job or API request sends the URL and selected job options to nData and creates a persisted job.
Processing flow and access
- nData records the submitted URL, prompt or output instructions, options, workspace, status and credit reservation.
- The API sends an accepted job to the separate private processor over an authenticated service boundary.
- The processor retrieves public post information and media as needed, then may use configured speech-recognition and model services. Necessary content can be sent to those providers. Their names, regions, terms and data-use settings are not specified in this public draft.
- nData stores the job result in the submitting workspace and makes it available to authorized workspace members through the portal or API. If configured, webhook delivery sends the event and result to the destination supplied in the request.
The API and processor have separate runtimes and databases. nData uses workspace access checks, member roles and scoped API keys. The source cache is shared internally for public-source efficiency, but prompt-derived evidence and final job results remain scoped to their workspace or execution.
Retention, closure and deletion
There is no published retention schedule. Prompts, schemas or templates, source URLs, results, transcripts and job/accounting history are stored with service records. Completed source files and metadata are retained after successful processing, failures, timeouts and retries. There is no scheduled deletion of source files, and no exact deletion period is promised. Support-ticket retention is also indefinite until the operator sets a policy.
Closing a workspace revokes its keys and invitations, removes memberships and preserves financial and job history. Confirmed account deletion revokes account keys and sessions, removes memberships and direct profile identifiers, and records a deletion tombstone. It requires recent authentication, verified email, and transfer or closure of any workspace the account owns. Job and accounting history remains for attribution and financial history.
Account deletion does not automatically purge retained source files, shared cache entries, job inputs, results or every provider copy. Use support to request access, correction or removal. nData will review the request, but there is no self-service source purge or promise of complete removal in this beta description.
Security measures and limits
Current controls include Django-managed password hashing and sessions, CSRF checks on session mutations, verified identity flows, optional customer MFA by default, required MFA for nData staff and workspaces with an explicit policy, workspace and role authorization, revocable scoped API keys, authenticated private API-to-processor calls, separate service databases, encrypted webhook secrets, and restricted media-decoder execution. Enrolled accounts complete MFA at sign-in. Operational security events are designed to retain metadata rather than prompts, schemas, source URLs, raw API keys or provider exception bodies.
These are implementation measures, not a certification, penetration-test statement, guarantee against unauthorized access, or promise about every deployment. Production security depends on operator configuration and the providers used. Model outputs may be inaccurate; schema validation confirms shape, not truth.
Questions and requests
Use the support form and select the privacy category for access, correction or removal requests. Include enough detail to identify the account or record, but do not include API keys, passwords, private-source credentials or unrelated sensitive information. The form will show whether the ticket was stored locally or queued for email. No response time is promised.
Operator identity, jurisdiction, provider and transfer details, applicable rights, pricing and exact retention periods still require confirmation. nData must publish those details before this draft can become a final notice.