Skip to main content

​
General

The production endpoint https://api.novatrade24.com/v1 is live, with access restricted to pilot customers, and every request needs client credentials. The specification itself is still a draft. Production availability is coordinated per pilot customer.
A hosted Prism mock at https://mock.api.novatrade24.com serves stub responses from the spec so you can exercise request/response shape. Full functional staging (https://api.stage.novatrade24.com) opens to pilot customers during onboarding.
No. API calls are rejected with 403 dpa-not-accepted until the DPA is signed and registered on your organization. This is a hard gate.
Not yet. Generate your own from the OpenAPI spec with openapi-generator-cli in your target language.

​
Auth and credentials

Yes. Common setup is one client per consuming system (e.g. your DMS plus your accounting tool). Each client has its own credentials but shares the same IntegrationOrganization scope and capability flags.
Contact support to regenerate. Both old and new secrets are valid during a rotation window (typically 24-72h) so you can migrate without downtime.
No. An IntegrationOrganization can have multiple authorized partners; every partner-scoped URL takes the partner UUID in the path. One API client can act on behalf of all authorized partners within its org.

​
Buyers and KYC

Just POST, the API upserts by (sellerId, vatNumber). First call creates; subsequent identical calls return the existing record with 200.
Upgrades A → B are allowed via PATCH. Downgrades B → A are not. IDenfy and AML artifacts are legal records that can’t be retroactively de-scoped.
Generate a self-service invitation (POST /buyers/{id}/kyc/self-service-invitations). The buyer receives an email with a branded upload link. Their submissions flow in the same way as API-uploaded documents, no branching in your code.
No. VIES checks are async workflows; pending/unknown results don’t block other operations. The compliance rollup reports viesResult: PENDING / UNKNOWN until VIES recovers.

​
Orders

Yes. VIN is not unique platform-wide, a vehicle may reappear in multiple orders over time (resale, buyback). GET /orders?vin={vin} returns all matches scoped to your authorized partners.
Most likely: the {sellerId} in the URL path is not in your org’s authorized partners list, or a required capability is not granted. Run GET /v1/me and check.
Cancellation works via POST /orders/{uuid}/cancel while the order is open — complianceStatus: INCOMPLETE. Once NT24 staff have closed the order (VALID), cancellation is restricted: contact support. A cancelled order reports complianceStatus: CANCELLED.

​
Transport

Call POST /transport/pickup again with the correct date. It replaces the recorded one. There is no revoke endpoint: NT24 records steps that have already happened, so a pickup cannot be undone — only the date it was recorded under can be corrected.If the pickup never happened at all, that is a data error rather than a step of the process. Contact support; the operation requires a pickupDate, so it cannot be used to clear one.
You can read them, not record them. When NT24 staff split an order across several shipments, each shipment has its own transport, and GET /transport reports each vehicle’s state in vins[] next to the order-level state, which stays PICKUP_CONFIRMED until the last transport arrives. The pickup, delivery and document writes are order-scoped and answer 409 on a split order. See Transport.
Upload a replacement document (same type). Documents are append-only; supersede the bad upload with PATCH setting status: ARCHIVED on the old record. Latest ACTIVE document counts.

​
Webhooks

Root wildcard (*) is not supported, explicit opt-in at least at the segment level (compliance.*, kyc.*). This prevents accidental firehose subscriptions.
Probably not. NT24 retries for up to 72 hours (10 attempts with exponential backoff). If your endpoint comes back in time, events are delivered. For longer outages, the delivery history endpoint lets you replay events within 30 days.
At the per-endpoint level, best-effort, but retries can reorder deliveries. Design handlers to be order-independent and keyed on the resource state (compliance rollup version, etc.), not on event order.
Non-2xx responses are treated as failures. 4xx responses still count against the retry budget, the retries continue on schedule. If you want to signal “don’t retry, I reject this”, return 200 OK and swallow the event silently on your side.

​
Errors and retries

The body changed between retries. Safe retry requires identical key AND identical body. Fresh data = fresh key.
Not yet. Rate limiting is planned and not enforced today, so no endpoint answers 429. Still avoid busy-loop retries; see Rate limits.
Yes. The server returns Cache-Control hints; we recommend an in-process 5-minute TTL on the org’s partner list and capabilities. Capability changes are rare.

​
Next

Error reference

Full problem-type catalog.

Contact

Ask anything not covered here.