Skip to main content
This page summarizes the security and compliance posture of the Novatrade24 Integration API. It is intended as a starting artifact for your legal, privacy, and security reviewers, not as legal advice. For a full controller/processor relationship description, see DPA. For data-subject rights, see GDPR.

​
Data Processing Agreement (DPA)

Integration API access is gated on an executed DPA between your organization and Novatrade24. The DPA:
  • Classifies the parties’ roles (controller / processor / joint controllers) per data category.
  • Specifies sub-processors, data categories, and lawful basis.
  • Enumerates data-subject rights handling and breach notification timelines.
Technically, the API stores the DPA version your organization accepted (dpaVersion + dpaAcceptedAt) and rejects every API call with 403 when the DPA is missing or out of date. Renewal follows a documented process: new DPA version → email notification → grace window → enforcement. Inspect your DPA state via GET /v1/me:

​
Authentication

  • OAuth 2.0 client_credentials via Keycloak service accounts (realm nt24-idp). See Authentication.
  • Short-lived bearer tokens (typical 5 min).
  • Rotatable client_secret per customer.
  • No per-user login, no credential persistence in your backend beyond the client_secret you manage.

​
Authorization

Multiple layers:
  1. Organization scope: your API client is bound to one IntegrationOrganization. Cross-organization access is impossible.
  2. Authorized partners: every partner-scoped URL (/partners/{sellerId}/...) validates {sellerId} against your org’s authorized partners list.
  3. Capability flags: commercial features (e.g. allowMarketplaceLedKyc, allowMultiVinOrders) are independently provisioned per organization. Denied features return 403 regardless of valid token. No capability decides what data you may see — that follows the seller’s own access, via layer 2.

​
Encryption

Document binaries live on EU object storage (Germany) with server-side encryption and pre-signed access URLs.

​
Data residency

  • All Integration API data stored in Germany.
  • Payment processing via Stripe involves a transfer to the United States covered by Standard Contractual Clauses. All other sub-processors operate within the EU/EEA. Current list in the DPA.
  • No replication outside the EU for platform data. If your compliance program requires in-country hosting outside Germany, that is a bespoke engagement and not supported in the standard offering.

​
Audit trail

  • Every API call logged with actor (API client UUID), partner context, endpoint, response status, timing, and request id. Access logs retained for 1 year.
  • Entity-level revision history captures who changed what and when. Integration API writes are attributed to the API client UUID, distinct from web-app user writes. Audit trail retained for 10 years (matching tax-record retention).
  • PII-bearing endpoints (personal contact data reads, KYC document downloads) accept an X-Purpose header so callers can record justification on the access record.

​
Personal data handling

  • Data minimization by default. GET /buyers/{id} returns the buyer record: type, name, company number, address, status, and the VAT number where the platform holds one. Contact people are on the /contacts sub-resource, reachable for every buyer the seller can resolve.
  • A CONSUMER buyer is a natural person. Their full name and address are the buyer record, so that read hands you personal data. See GDPR.
  • KYC document downloads (ID scans, bank statements) follow the seller’s own KYC access to the buyer and are recorded in the access log.
  • Right to erasure: NT24 honors data-subject erasure requests subject to legal retention obligations (VAT records: 10 years in EU). Records required by law remain; freeform personal fields are erased. A future webhook (buyer.erasure_required) will notify your system to cascade deletion in your own datastores.

​
Breach notification

NT24 notifies affected organizations promptly on incidents meeting the classification criteria in the DPA. Notifications include:
  • Nature, scope, and data categories affected.
  • Mitigations applied.
  • Recommended customer-side actions.

​
Availability posture

No formal SLA during pilot. Incidents are communicated via email to organization admins. Contractual availability targets will be defined before general availability.

​
Sub-processors

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

​
Reporting a security concern

Responsible disclosure: [email protected]. We acknowledge within 3 business days.

​
Next

GDPR details

Lawful basis, subject rights, retention overrides.

DPA

Controller/processor relationship, breach notification timelines.