Skip to main content
This page explains how the Integration API handles personal data under the GDPR (EU Regulation 2016/679). It is a technical summary of what the API does, the legally authoritative document is the DPA.

​
Personal data categories handled

​
Lawful basis

  • Contract performance: processing buyer identification, documents, and transaction data is necessary to perform the compliance evaluation contracted via the DPA.
  • Legal obligation: VAT compliance evidence (10-year retention in EU member states) overrides erasure in narrowly-defined cases.
  • Legitimate interest: audit logging, fraud detection, platform integrity. Documented in the DPA.
Consent is not the primary basis for platform processing, it would be unworkable in B2B transactions. Explicit consent may be required for specific downstream uses (e.g. marketing, not part of Integration API).

​
Controller / processor

Novatrade24 is typically a processor for customer data you provide via the Integration API. Your organization is the controller for the data on the buyers you submit. Joint-controller arrangements exist for certain categories, see your DPA.

​
Data minimization

The API is designed to minimize surface area for personal data:
  • GET /buyers/{id} returns the buyer record only: no contact people, no documents. Where that buyer is a legal entity the record holds nothing personal.
  • A buyer with type: "CONSUMER" is a natural person, and the record is about them: companyName is their full name, the address is their own. That data crosses on the ordinary buyer read — treat every consumer buyer you read as personal data in your own DPIA, retention schedule and erasure cascade.
  • Contact people of a buyer are a separate /contacts sub-resource. It carries what the seller you are acting for can already see about that buyer; no per-organization switch narrows it further. Adding one follows the same access, so a contact person you record on a buyer whose KYC record is shared becomes visible to every partner holding that record — one record per buyer, one set of contact people.
  • KYC document downloads follow that same access.
  • An order carries a contact person. responsibleContact holds a named individual’s first name, last name, email and phone, and it reaches you on order reads and lists — on every order that has one recorded, which is every order the platform still lets anyone write. It is the one place personal data reaches an integration that never asks for it: reading orders is enough.
  • Optional fields are omitted from responses when empty. Reading only COMPANY buyers, and nothing else, is the only shape of integration that sees no personal data at all.

​
Data subject rights

​
Access / portability

Customer can export their own data via existing endpoints (GET /buyers/{id}, GET /orders/...). Per DPA, Novatrade24 assists in fulfilling data-subject-access requests that reach either party.

​
Rectification

Via PATCH on the relevant resource (buyer, contact). The entity’s version bumps and the change is recorded in the audit trail (who, what, when). The “who” is the calling organization and the partner it acted for, both recorded on the revision itself. This matters because the buyer record is shared: one KYC result may be held by several partners, and each of them can PATCH the same row. Support can therefore answer which partner made a given change, which is what settles a rectification dispute between two of them. The authenticated principal alone cannot answer it — an API token is a service account, and one organization may be authorized for several partners.

​
Erasure

Complicated by overlapping obligations:
  • Data subject requests erasure.
  • Platform has legal retention obligation (VAT: 10 years).
  • Integration customer may have independent retention obligation.
Process:
  1. Request reaches NT24 or customer.
  2. NT24 evaluates retention overrides per DPA.
  3. Non-required freeform fields erased.
  4. Records required by law remain with minimal fields (VAT, amount, date, buyer name for the invoice).
  5. A future webhook will notify customer to cascade deletion in their own datastore.

​
Objection / restriction

Per DPA. The Integration API does not provide a self-service object-to-processing endpoint; route via support.

​
Retention

For the full retention schedule see the internal Data Retention Policy (GDPR-DRP-001).

​
Encryption

  • TLS 1.2 minimum, TLS 1.3 preferred. Older protocols rejected.
  • AES-256 at rest on databases and object storage.

​
International transfers

  • All Integration API data stored in Germany.
  • Stripe (payment processing) is the one transfer outside the EU/EEA, to the United States, covered by Standard Contractual Clauses. All other sub-processors operate within the EU/EEA. Current list in the DPA.

​
Audit trail

  • Every API call logged with caller identity (API client UUID), partner context, endpoint, timing, status, trace id.
  • Entity-level revision history records every write with actor attribution (API client vs. web-app user).
  • PII-bearing endpoints (contact-data reads, KYC document downloads) accept an X-Purpose header to record per-request justification on the access record.

​
Breach notification

Per DPA, NT24 notifies affected organizations promptly when a security incident meets the classification criteria. Notifications include:
  • Nature, scope, data categories affected.
  • Estimated affected data subjects.
  • Mitigations applied.
  • Recommended customer actions.
GDPR’s 72-hour authority notification deadline applies to NT24 as controller for its own platform data. For processed data, NT24 notifies the customer promptly so the customer (as controller) can meet their own obligation.

​
Sub-processors

Authoritative list maintained in the DPA. Customer is notified before new sub-processors are added.

​
Reporting a GDPR concern

​
Next

DPA

Authoritative controller/processor terms.

Security overview

Encryption, residency, audit.