Data Portability Register

Technical information for Now4real Publishers

Last updated: 2026/09/21

This Data Portability Register (the “Register”) supplements Article 14 of the Now4real Publisher Terms of Service. It describes the available export and switching procedures, data categories, file structures, formats, standards, security measures, and known technical limitations applicable to Exportable Data and Digital Assets.

The Register is technical and informational. It does not expand or reduce the exhaustive categories included in or excluded from Exportable Data and Digital Assets under Articles 14.5 and 14.6 of the Publisher Terms of Service. If this Register conflicts with the Agreement, the Agreement controls.

1. Purpose and Legal Status

1.1. This Register is intended to help Publishers and their authorized destination providers understand how data can be retrieved from Now4real, transferred to another environment, or made available for an orderly switching process.

1.2. It applies to Publisher accounts, the Websites registered under those accounts, and the data and configurations generated, supplied, or configured in connection with the Services, to the extent retained by or available to N4R at the time of export.

1.3. Capitalized terms not defined in this Register have the meanings given in the Publisher Terms of Service, available at https://now4real.com/publisher-terms/.

1.4. This Register concerns contractual data portability and switching for Publishers. Requests by individuals to exercise data-protection rights are governed by the applicable privacy documentation and, in WL Mode, by the Publisher’s instructions under the DPA.

2. Export Availability

2.1. Available Interfaces and Formats

 

Data category	Access method	Format	Scope
Publisher account and administrative data	Request to N4R support; delivery through Dashboard	ZIP containing JSON	Request-based
Billing and subscription data	Request to N4R support; delivery through Dashboard	ZIP containing JSON	Request-based; invoices are separate PDF files
Invoices	Dashboard	PDF only	One PDF document per invoice
Website configurations	Request to N4R support; delivery through Dashboard	ZIP containing JSON	Request-based
Chat Data	Dashboard; N4R support for additional request-based exports	JSON; ZIP containing JSON	Messages self-service; additional retained Chat Data on request
Analytics	Dashboard	JSON or CSV	Self-service
WL End User profile and access data	Request to N4R support; delivery through Dashboard	ZIP containing JSON	Request-based; WL Mode only

 

2.2. Self-service exports contain the data currently exposed by the relevant Dashboard function. Request-based exports may combine multiple categories in one archive and may include additional records that are retained by N4R but are not present in the corresponding self-service file. Once prepared, request-based ZIP archives are made available for secure download through the Publisher’s authenticated Dashboard.

2.3. A request-based export is a logical export of the Publisher’s data. It is not a copy of N4R’s internal database and does not reproduce proprietary database schemas, service architecture, source code, or internal operational data.

2.4. Only data relating to the requesting Publisher and its Websites are included. Data belonging to another customer or third party are excluded unless N4R is legally entitled and required to disclose them.

3. How to Request an Export or Switching Assistance

3.1. The Publisher may submit a written request to support@now4real.com. The request should state whether the Publisher wishes to:

• receive its Exportable Data and Digital Assets directly;
• have them transferred or made available to an authorized destination provider;
• port them to an on-premises ICT infrastructure;
• erase them without switching to another service; or
• where applicable, facilitate the in-parallel use of another data processing service.

3.2. The request should identify the Publisher account, the relevant Websites, the requested data categories and time period, and any authorized recipient. N4R may request information reasonably necessary to verify the requester’s authority and securely authenticate the recipient.

3.3. A complete and verifiable request to switch to another provider, port data to an on-premises ICT infrastructure or, where applicable, facilitate in-parallel use starts the transitional period described in Article 14 of the Publisher Terms of Service. A request to erase Exportable Data and Digital Assets without switching does not start a transitional period and is handled in accordance with Article 14.9(b). N4R will complete the source-side actions for which it is responsible without undue delay and, subject to the technical extension procedure in Article 14.4, within 30 calendar days.

3.4. N4R does not impose a switching charge. Normal Subscription Fees continue to apply while the Agreement and Services remain in effect. Optional professional services that exceed the assistance required under Article 14 may be separately agreed and charged.

3.5. N4R and the Publisher may agree on reasonable delivery details, including archive splitting, a secure transfer channel, recipient authentication, and a staged delivery for particularly large exports.

4. Formats and General Conventions

4.1. Supported Formats

• JSON is the primary format for structured operational data. JSON files are encoded in UTF-8 and conform to RFC 8259.
• CSV is available as an alternative self-service format for Analytics. CSV files are encoded in UTF-8 and contain a header row.
• PDF is the exclusive format for invoices. N4R does not currently provide a JSON or CSV representation of invoices.
• ZIP is used as the container for request-based exports containing multiple files or data categories.

4.2. Current Self-service JSON Structure

Current Chat Data and Analytics JSON exports consist of a top-level JSON array. They do not use a common JSON envelope. Each array element represents one chat message or one Analytics measurement interval, respectively.

The Website and selected time interval may also be identified by the Dashboard export context and filename. Filenames are descriptive and are not a stable application programming interface.

4.3. Field Conventions

• field names use camelCase unless a documented file specifies otherwise;
• dates and times use ISO 8601 format, and UTC timestamps end in Z;
• identifiers are opaque strings and must not be interpreted as sequential values;
• optional fields may be omitted when they do not apply;
• a field may contain null where the field applies but no value is available;
• decimal numbers use a period as the decimal separator;
• Boolean values use the JSON values true and false; and
• text is encoded in UTF-8.

4.4. Schema Evolution

N4R may add optional fields, new documented code values, or additional files without changing the meaning of existing fields. Material or incompatible changes will be reflected in this Register. Request-based archives identify their schema version in the manifest.

5. Request-Based Archive Structure

5.1. A request-based export may use the following directory structure. Only files relevant to the requested scope are included.

manifest.json

checksums.json

publisher/

    account.json

    administrativeData.json

billing/

    billingProfile.json

    subscriptions.json

invoices/

    {invoiceNumber}.pdf

websites/

    {websiteId}/

        configuration.json

        moderationPolicies.json

        automatedAgents.json

chat/

    {websiteId}/

        messages.json

        messageHistory.json

        reactions.json

        reports.json

        moderationEvents.json

        automatedAgentInteractions.json

analytics/

    {websiteId}/

        counters.json

        reports.json

wlEndUsers/

    {websiteId}/

        users.json

5.2. The manifest.json file may contain:

• schemaVersion: the version of the export schema;
• exportId: the unique identifier of the export;
• generatedAt: the UTC time at which the export was generated;
• publisherId: the opaque internal identifier of the Publisher;
• requestedPeriod: the requested time interval, where applicable;
• includedWebsites: the Websites included in the export;
• includedCategories: the data categories included in the export;
• files: the files contained in the archive, with their category and size; and
• notes: any limitations or explanatory information applicable to the specific export.

5.3. Where supplied, checksums.json contains SHA-256 checksums that allow the recipient to verify file integrity after download or transfer.

5.4. The precise directory names may evolve with the schema version. The manifest is authoritative for the contents of a particular request-based archive.

6. Data Category Specifications

The schemas in Sections 6.1, 6.2, 6.3, 6.4.4, 6.5.2, 6.6 and 6.7 describe the planned logical content of request-based exports. They are preliminary until the related database and implementation review is completed. Fields are included only where applicable and retained by or available to N4R.

6.1. Publisher Account and Administrative Data

The Publisher account export may contain:

• publisherId and other opaque internal account identifiers;
• account or organization name, contact name, and contact email address;
• authentication method or external account identifier, without passwords, tokens, or other credentials;
• company or legal name and administrative contact details;
• account creation, status, and closure information, where retained;
• the list of Websites registered under the account; and
• administrative preferences and account-level settings.

Authentication secrets, password hashes, access tokens, refresh tokens, API keys, and cryptographic material are not included.

6.2. Billing, Subscription, and Invoice Data

The structured billing and subscription export may contain:

• billing name, company name, billing address, country, VAT number, or other tax identifier;
• Subscription plan, status, activation date, billing cycle, and applicable usage limits;
• payment status, transaction references, and other billing information available to N4R;
• a payment-method summary, such as payment method type, card brand, last four digits, and expiration date, where available to N4R; and
• invoice references and the relationship between invoices, Subscriptions, and payment records.

Complete card numbers, card security codes, PayPal credentials, gateway credentials, and other complete payment credentials are never included.

Invoices are available exclusively as individual PDF documents. If included in a consolidated archive, they remain PDF files in the invoices directory and are not converted into JSON or CSV.

6.3. Website Configurations

The Website configuration export may contain:

• websiteId, Website name, domains, origins, and other Website identification data;
• WL Mode or NWL Mode configuration;
• enabled Service features and relevant Widget or Client API settings;
• chat access, visibility, presence-counter, and message-duration settings;
• Access Procedure and Custom Authentication configuration, excluding secrets and signing keys;
• moderator roles, permissions, and moderation settings;
• profanity filters, moderation policies, and Publisher-defined AI Moderation policies;
• welcome messages, page or Website structures, and other Publisher-created configuration content;
• Automated Agent endpoints, behavior settings, and Publisher-created instructions, excluding credentials and N4R proprietary system instructions; and
• other optional feature settings associated with the Website.

The export represents configuration data in a portable logical form. It does not reproduce N4R’s internal database tables or guarantee that another provider offers equivalent configuration concepts.

6.4. Chat Data

6.4.1. Current Self-service Message Export

The current Chat Data JSON export is a top-level array containing one object for each exported chat message. Messages are ordered from the most recent to the oldest.

 

Field	Type	Required	Description
id	string	Yes	Opaque internal identifier of the message.
time	string	Yes	UTC date and time associated with the message, in ISO 8601 format.
siteName	string	Yes	Name of the Website associated with the message.
page	string	Yes	Page URL, path, or other page identifier associated with the Chat.
content	string	Yes	Message content retained in the message record.
publishedContent	string	Yes	Version made available in the Chat after applicable processing. It may differ from content or be empty if the message was not published or was later removed.
deleteCause	string	No	Reason code associated with non-publication or removal, where applicable.
edited	boolean	No	Indicates that the message was edited.
replyId	string	No	Identifier of the message to which this message replies.
userProfile	object	Yes	Profile information associated with the author of the message.

 

The following example is illustrative and does not contain real User data:

[

  {

    “id”: “message-id”,

    “time”: “2026-09-18T15:00:00Z”,

    “siteName”: “Example Website”,

    “page”: “/example-page”,

    “content”: “Example message”,

    “publishedContent”: “Example message”,

    “userProfile”: {

      “id”: “user-id”,

      “jwtSub”: null,

      “displayName”: “Example User”,

      “profileImageUrl”: null,

      “authProvider”: “NO_REGISTRATION”

    }

  }

]

6.4.2. userProfile Object

 

Field	Type	Description
id	string	Opaque internal identifier associated with the User.
jwtSub	string or null	Opaque subject supplied through Custom Authentication, where applicable.
displayName	string	Display name associated with the User.
profileImageUrl	string or null	URL of the profile image, where available.
authProvider	string	Code identifying the applicable Access Procedure or profile source.

 

6.4.3. Current Code Values

Current deleteCause values include:

• AI_MODERATION: the message was not published or was removed as a result of AI Moderation; and
• USER_AUTHOR: the message was removed by its author.

Current authProvider values include, among others, NO_REGISTRATION and CHATBOT. These lists are not exhaustive. New values may be introduced when Access Procedures or Service features change.

6.4.4. Additional Request-Based Chat Data

Where applicable and technically exportable, the request-based archive may also contain:

• messageHistory.json, containing retained versions or events associated with message edits and other message changes;
• reactions.json, containing message references, reaction values, associated User identifiers, and timestamps;
• reports.json, containing reported-message references, reporting and reported User identifiers, reasons, timestamps, and status information where retained;
• moderationEvents.json, containing message references, moderation decisions, reasons where available, relevant policy references, actor or system information, and timestamps; and
• automatedAgentInteractions.json, containing retained interaction records involving Automated Agents, including message or conversation references, inputs, outputs, timestamps, and non-secret configuration references.

The exact fields of these additional files will be finalized after the database and implementation review. External provider logs, provider-side model data, and credentials are not included merely because an Automated Agent or AI Moderation feature was used.

6.5. Analytics

6.5.1. Current Counter Export

The current JSON Analytics export is a top-level array of counter records ordered from the oldest to the most recent. Each record represents a three-minute measurement interval.

 

Field	Type	Description
time	string	UTC timestamp identifying the three-minute measurement interval.
ccMax	number	Maximum number of concurrent chatters measured during the interval.
ccAvg	number	Average number of concurrent chatters measured during the interval.
cvMax	number	Maximum number of concurrent viewers measured during the interval.
cvAvg	number	Average number of concurrent viewers measured during the interval.

 

The CSV variant represents the same counter records in tabular form, with the field names shown above as column headers.

The counters are aggregate measurements and do not identify individual End Users. Current JSON and CSV exports do not contain raw per-User presence events.

6.5.2. Additional Analytics and Reports

Where available in the Services and retained by N4R, a request-based export may also contain Website-level or page-level aggregate reports, Viewing Time information, and country-level aggregate distributions. The manifest identifies any additional Analytics files included in a particular archive.

6.6. WL End User Profile and Access Data

This category applies only to Websites configured in WL Mode, where N4R processes End User data on behalf of the Publisher.

The request-based users.json file is expected to be a top-level JSON array and may contain, where applicable and retained:

• userId: an opaque N4R internal identifier;
• websiteId: the Website to which the profile or access record relates;
• accessProcedure: the applicable nickname-based, email-based, or Custom Authentication procedure;
• displayName or nickname;
• email address and email-verification status, where the email-based Access Procedure is used;
• profileImageUrl or other profile-image reference, where available;
• jwtSub or another opaque subject supplied through Custom Authentication, where applicable; and
• profile creation, first-access, or last-access timestamps, where retained.

The final field list and filename structure will be validated against the production database before this export is released.

IP addresses contained only in ordinary server, diagnostic, or security logs are not included in the standard WL End User export. Passwords, password hashes, one-time verification codes, access tokens, refresh tokens, signing keys, and other authentication secrets are excluded.

6.7. Other Exportable Digital Assets

Other Publisher-created or Publisher-supplied digital assets may be included where they form part of the categories in Article 14.5 and are retained by or available to N4R. Examples include Publisher-authored moderation policies, Automated Agent instructions, welcome messages, feature settings, and other configuration content.

N4R software, algorithms, models, proprietary system instructions, internal prompts, internal schemas, service architecture, and third-party intellectual property are not exportable merely because they are used to operate a feature.

7. Standards and Interoperability

7.1. N4R uses commonly used formats and conventions to facilitate machine processing:

• JSON according to RFC 8259;
• CSV for tabular Analytics exports, following conventional header-row and UTF-8 practices;
• ISO 8601 date and time representations;
• ZIP archives for multi-file delivery;
• PDF documents for invoices; and
• SHA-256 checksums where checksums are supplied.

7.2. N4R does not currently claim conformance to a service-specific harmonized standard or open interoperability specification for one-to-one migration of group-chat, presence-analytics, moderation, or Automated Agent configurations.

7.3. No general automated import or mapping service is provided for configurations exported by another provider. This Register documents outbound portability from N4R. Any import into N4R, if offered in a particular case, is outside the standard switching procedure and may require a separate agreement.

7.4. The use of standard file formats does not imply semantic equivalence with another service. A destination provider may need to transform field names, map concepts, reconstruct relationships, or omit unsupported features.

7.5. The self-service export interfaces currently available are the authenticated Dashboard functions identified in Section 2.1. Programmatic export endpoints are not currently available. If N4R introduces programmatic export endpoints, their authentication requirements, supported operations, formats, availability to authorized destination providers and known technical limitations will be described in this Register.

8. Switching and Transfer Procedure

8.1. Delivery Methods

Self-service exports and request-based ZIP archives are made available through the Publisher’s secure, authenticated Dashboard. At the Publisher’s request, N4R may instead make a request-based export available to an authenticated and authorized destination provider through another secure transfer method.

8.2. Destination Provider

The Publisher is responsible for identifying and authorizing the destination provider. N4R may require sufficient recipient and security information before making data available to that provider.

8.3. Source-Side Assistance

N4R will perform the source-side actions required under Article 14, provide relevant information about the export, and use reasonable measures to maintain business continuity and security during the transitional period.

Unless separately agreed as an optional professional service, N4R is not responsible for selecting the destination service, redesigning the Publisher’s configuration, uploading or importing files into the destination environment, or validating the destination provider’s implementation.

8.4. Completion

A switching process is complete when N4R has made the applicable Exportable Data and Digital Assets available to the Publisher or authorized recipient, completed the other source-side actions required from N4R, and notified the Publisher, as further provided in Article 14.9.

8.5. In-parallel Use

Where in-parallel use is requested and technically applicable, the Parties will agree on the relevant scope and coordination. N4R does not guarantee real-time synchronization with another provider or identical behavior across services.

9. Security, Infrastructure Jurisdiction, and Governmental Access

9.1. Security and Integrity

• N4R verifies the authority of the requester and, where applicable, the identity or authorization of the destination recipient.
• Exports are delivered through HTTPS or another secure transfer method agreed with the Publisher.
• Download links or credentials may be time-limited and may be revoked after delivery or expiry.
• Credentials, complete payment data, cryptographic keys, API secrets, access tokens, and other secret material are excluded.
• Where supplied, SHA-256 checksums permit verification that files were not altered during transfer.
• The Publisher and destination provider are responsible for protecting exported files after delivery and for complying with applicable confidentiality and data-protection obligations.

9.2. Infrastructure Jurisdiction

N4R is established in Italy. The core production ICT infrastructure used to provide the Services and store Publisher and End User data is hosted by Amazon Web Services EMEA SARL in the AWS eu-west-1 region in Ireland. The core infrastructure is therefore located in the European Union and is principally subject to European Union law and applicable Italian, Irish, and Luxembourg law. AWS EMEA SARL is part of a corporate group headquartered in the United States, which may result in exposure to requests based on third-country law. Any such request involving non-personal data held in the European Union is assessed and handled under Section 9.3.

9.3. Safeguards Against Unlawful International Governmental Access

N4R adopts technical, organizational, and contractual measures designed to prevent international or third-country governmental access to or transfer of non-personal data held in the European Union where that access or transfer would conflict with European Union law or the law of the relevant Member State. These measures include:

• storing core production data in the European Union;
• access controls based on least privilege and appropriate authentication, together with logging and monitoring;
• encryption of data in transit and, where applicable, at rest;
• contractual security and data-protection commitments imposed on relevant service providers;
• assessment of governmental requests for legal validity, jurisdiction, scope, necessity, and proportionality;
• objection to or challenge of requests that N4R reasonably considers unlawful, overbroad, or incompatible with applicable European Union or Member State law, where legally available;
• consultation with a competent national body or authority where appropriate;
• disclosure only of the minimum amount of data lawfully required; and
• notice to the affected Publisher before compliance, unless the request serves law-enforcement purposes and notice must be delayed for as long as necessary to preserve the effectiveness of the relevant activity, or notice is otherwise prohibited by applicable law.

10. Excluded Categories

Consistently with Article 14.6 of the Publisher Terms of Service, the following are excluded:

• the Software, source code, object code, algorithms, models, proprietary system instructions, internal database schemas, service architecture, know-how, and other technology belonging to N4R or a third party;
• internal operational, diagnostic, telemetry, performance, capacity-management, security, fraud-prevention, investigation, and administrative data generated by N4R solely for the internal functioning, protection, or management of the Services, where disclosure would expose trade secrets or compromise security or service integrity;
• passwords, password hashes, authentication or access tokens, cryptographic keys, API secrets, complete payment credentials, and other credentials or secret material;
• data or digital assets belonging to another customer or third party that N4R is not legally entitled to disclose; and
• data held solely by independent third parties and not available to N4R or its processors.

These exclusions do not exclude the Publisher’s input or output data merely because those data are stored within N4R’s systems.

11. Known Technical Limitations

• The export is limited to data retained by or available to N4R at the time the export is generated. Data already deleted under the applicable retention rules cannot be reconstructed.
• The current self-service Chat Data export is a flat array of message records. Separate reaction, report, history, moderation, or Automated Agent datasets are not contained in that file.
• Current counter Analytics use three-minute aggregate intervals. Raw per-User presence events are not included.
• Current self-service Chat Data and Analytics JSON files do not contain a schema envelope or archive manifest.
• Optional fields may be absent, null, or unavailable depending on the Website mode, Access Procedure, enabled features, and historical product configuration.
• Large exports may be divided into multiple ZIP archives or delivered in stages.
• Another provider may not support all N4R concepts or features, and exported configurations may not be directly importable without transformation.
• N4R cannot export provider-side data held solely by an independent third party and unavailable to N4R or its processors.
• Removal, moderation, retention, and privacy settings may affect which Chat Data or End User records remain available at the time of export.

12. Retrieval, Retention, and Erasure

12.1. Following the end of the transitional period, or following termination where no transitional period applies, N4R makes the applicable export available for retrieval for at least 30 calendar days, as provided in Article 14.9. Throughout that period, N4R maintains authenticated access to the Dashboard functions necessary to download the applicable self-service exports and any request-based ZIP archives made available there. Other Dashboard functions may be disabled.

12.2. After the retrieval period, or after a later period agreed with the Publisher, N4R erases Exportable Data and Digital Assets generated directly by or relating directly to the Publisher, provided that any applicable switching process has been successfully completed, and subject to legal retention obligations, the DPA where applicable, and the other provisions of the Agreement.

12.3. Billing, tax, invoice, transaction, dispute, and other records may be retained for the period required by applicable law or reasonably necessary for the establishment, exercise, or defense of legal claims. Data retained for those purposes are restricted accordingly and are not kept available for ordinary Service use.

12.4. Personal data processed by N4R on behalf of a Publisher in WL Mode are returned or erased in accordance with the DPA and the Publisher’s lawful instructions.

13. Updates to This Register

13.1. N4R may update the technical contents of this Register to reflect changes to the Services, export formats, file structures, fields, standards, or available procedures.

13.2. Updates to this Register will not materially reduce the Publisher’s mandatory switching rights or the categories of Exportable Data and Digital Assets identified in Article 14.5 of the Publisher Terms of Service.

13.3. The schemaVersion in a request-based archive identifies the schema applicable to that archive. The Register in effect when the export is generated describes the corresponding technical format.

14. Contact

Requests for exports, switching assistance, or technical clarification should be sent to support@now4real.com.

Questions concerning personal-data processing or data-protection rights should be sent to privacy@now4real.com.