Scope and operator
This draft covers the nData public beta, including its website, account portal, API, support form, and extraction and transcription jobs. The service is still being prepared for public operation. The legal operator, jurisdiction, applicable legal bases, and data retention schedule have not been confirmed.
Use the support form for privacy questions or requests. Its saved or emailed status is shown when you submit. The form does not promise a response time.
Information nData handles
Depending on how you use nData, the service may handle:
- Account details such as your name, email address, verified-email state, login and recovery information, MFA or connected identity-provider records, and account security events.
- Workspace details such as workspace names, membership roles, invitations, access settings, API-key records and usage limits. API keys are shown once when created; nData does not return their secret value in later responses.
- Job request data, including the public-post URL, extraction prompt, output schema or Markdown template, transcription options, job status and timestamps, and the result or error.
- Source information retrieved from a supported public post, such as its title, caption or body, public author details, media, metadata and source-provided transcript. Generated transcripts and extraction evidence may also be produced.
- Credit reservations and settlement, job and usage history, and billing or subscription event details when billing features are enabled.
- If you use a webhook, its destination URL and an encrypted signing secret. Webhook events contain job results or failure details as described in the API documentation.
- If you contact support, the category, message, reply email, and any contact details or other information you choose to include. Support tickets are stored durably in encrypted form. If no support email is configured, the ticket is saved in nData and is not emailed; if one is configured, nData queues it through its email system. Support-ticket retention is indefinite until the operator sets a retention policy.
- Limited operational records, such as resource identifiers, timestamps, status codes and bounded counters used for security events, quotas, billing reconciliation and troubleshooting. The security-event record is designed to exclude raw keys, prompts, schemas, source URLs and provider exception bodies.
The anonymous playground uses static sample data and does not submit a processing job. A signed-in job or API request is different: nData stores the request and its eventual result.
How processing works
The current beta accepts URLs for individual public posts on supported platforms. It does not support private or authenticated feeds, profiles, general searches, or access through your logged-in social account. A submitted prompt or schema is retained with the job.
To acquire and process a post, nData may send the necessary URL and public post content, media, transcript, prompt, schema or template to the processor and the source, speech-recognition, or model services configured for that deployment. Provider names, processing locations, transfer arrangements, and provider-specific data settings have not been confirmed in this public draft. nData makes no claim here that provider processing is limited to a particular region or that providers do not use submitted content to improve or train their models. Do not submit confidential material or sensitive personal information.
nData's API and private processor use separate service runtimes and databases. A shared internal cache may reuse public metadata, media, and prompt-independent transcripts for the same canonical public source URL across workspaces. Prompt-derived evidence and completed job results are scoped to the workspace or execution that produced them. Members with access to that workspace can access its jobs and results according to their role.
Why information is used
nData uses information to create and secure accounts, manage workspace access, accept and process jobs, return results, enforce quotas and credits, deliver configured webhooks, provide support, prevent abuse, maintain and troubleshoot the service, and handle billing events when enabled.
These are descriptions of current product functions, not a complete legal-basis statement. The operator must confirm the purposes and lawful bases that apply before launch.
The browser uses session and CSRF cookies for sign-in and secure form submissions, and browser storage to resume account flows. The current site requests web fonts from Google Fonts; that service receives connection information when your browser loads its files.
When configured, nData sends limited error events to Sentry to diagnose application failures. Before sending an event, nData removes request contents and URLs, account details, breadcrumbs, and local variable values. Sentry receives the exception type, a redacted message, code frames, release and environment, plus technical connection information carried by the network request. Sentry error monitoring is separate from the optional sharing with PostHog described below.
Optional feature measurement
nData uses PostHog to see which features people use and improve the app. This optional sharing is off by default. In Privacy choices, Accept turns it on and Reject turns it off.
When enabled, nData stores a random identifier in your browser and sends it to PostHog with named events and fixed categories. Events exclude email, URLs, source content, prompts, schemas, results, account or job identifiers, and balances. Autocapture, page tracking, session replay, identity linking, and marketing tracking are disabled. The PostHog project is configured to discard client IP addresses.
Your choice is saved in this browser. You can change it at any time in nData settings or through Privacy choices.
Sharing and access
nData makes job inputs and results available to authorized members of the workspace that submitted them and passes necessary content to the configured processor and external services used for source acquisition, transcription, model processing, hosting, identity, email, and billing. The exact providers and their roles need to be published by the operator.
Public-source cache entries are the exception to workspace-only storage: public metadata, media and prompt-independent transcript artifacts can be reused across workspaces for the same canonical source. Workspace prompts, prompt-derived evidence and job results remain workspace-scoped. nData does not expose another workspace's job or result through the public API.
A configured webhook receives the accepted event and job result at the destination you supplied. Check that you control the destination and are prepared to store its payload.
Retention and deletion
Exact retention periods are undecided. nData stores submitted source URLs, prompts, schemas or templates, results, and job and credit history. The processor retains completed source files and metadata, including after success, failure, timeout, and retry. There is no scheduled automatic deletion of retained source files. Do not assume a job, prompt, schema, result, transcript or media file will be automatically removed after a set time.
The account-deletion flow requires recent authentication, a verified primary email address, and transfer or closure of any workspace you own. On confirmed account deletion, nData revokes account keys and sessions, removes memberships and direct account identifiers, and records a deletion tombstone. Job and accounting history is retained for attribution and financial history. This flow does not promise a full purge of source files, cache entries, job content or all related records.
Request access to, correction of, or removal of information through support. nData will review each request, but this draft does not promise a specific response time, an automatic deletion mechanism, or complete removal from every system or provider. The operator must confirm applicable rights, procedures, exceptions and retention periods.
Security and accuracy
The implemented service uses authenticated sessions, scoped and revocable API keys, workspace access checks, a private authenticated processor boundary, separate API and processor data stores, encrypted webhook secrets, and restricted media-decoder execution. Security events are limited to operational metadata. These are implementation details, not a security certification or a guarantee that every deployment has identical protections.
Extraction and transcription results are generated from available public-source material and may be incomplete, inaccurate, or out of date. A source can change while nData's retained copy does not refresh. Check results against the original source before relying on them.
Changes and open details
This beta draft may change as the service and its operating arrangements are confirmed. The page date identifies the current product description, not a legal review. nData will need to publish a confirmed operator identity, jurisdiction, provider list and locations, retention periods, support handling, and applicable rights information before the terms are final.