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: 
{
  "dpaVersion": "2026-01",
  "dpaAcceptedAt": "2026-02-15T10:00:00Z"
}

​
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 — features (e.g. allowMarketplaceLedKyc, allowContactPersonalData, allowKycDocumentDownload) are independently provisioned per organization. Denied features return 403 regardless of valid token.

​
Encryption

ScopeStandard
In transitTLS 1.2+ enforced. Older protocols rejected.
At restDisk-level encryption on database and object storage.
Sensitive fieldsField-level encryption on bank account numbers and identity document scans.
Document binaries live on Hetzner S3 (Germany, EU) with server-side encryption and pre-signed access URLs.

​
Data residency

  • All data stored in Germany (Hetzner Falkenstein data centers).
  • No third-country transfers for platform data. Limited third-party services (Stripe, iDenfy) operate in the EU; see DPA for sub-processor list.
  • No replication outside the EU. If your customer’s 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. Retained per compliance requirements.
  • Hibernate Envers on the domain model provides entity-level revision history (who changed what, when). Integration API writes are attributed as api_client:{uuid} in the Envers modifier column, distinct from web-app user writes.
  • PII-access separate log stream with 6-year retention for reads of personal contact data and KYC document downloads. Caller can provide X-Purpose header to record justification.

​
Personal data handling

  • Data minimization by default. GET /buyers/{id} returns company-level data only (VAT, company name, address). Personal contact data is on the /contacts sub-resource, which requires the allowContactPersonalData capability.
  • KYC document downloads (ID scans, bank statements) require allowKycDocumentDownload and are logged to the PII-access stream with 6-year retention.
  • 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

PhaseCommitment
Phase 1 (pilot)Best effort, no formal SLA. Public status page planned; incidents communicated via email to organization admins until then.
Phase 2 (GA)99.5% uptime informal target. HA infrastructure.
Phase 3 (enterprise)99.9% contractual SLA for ENTERPRISE tier.
No published latency SLA. Target latencies documented in API Reference: reads < 500ms P99, writes < 2s P99.

​
Sub-processors

Current platform sub-processors handling customer data:
  • Hetzner Online GmbH (hosting, Germany)
  • Keycloak (authentication — self-hosted on Hetzner)
  • Stripe (payment processing, EU)
  • iDenfy (KYC verification, EU)
Full current list in the DPA.

​
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.