Guides
Start typing to search…

Limits & Performance

This page summarizes practical limits, scalability expectations, and performance patterns when working with Operations.

Keep in mind

  • Large payloads are expected: thousands of lines and accounts per Operation.
  • All list endpoints are paginated and should be combined with filters.
  • Keep heavy diffs and searches server-side when possible. Avoid fetching entire Operations on the client for comparisons.

🔢 Capacity overview

  • Product variants per Operation: up to ~5000 lines observed in production scenarios.
  • Accounts per Operation: up to ~1500 attached accounts.
  • Concurrent active Operations: several hundreds in parallel.

These figures are indicative guidelines to size UI and batch workflows.

graph TD
    A[Operation capacity] --> V[Product variants per Operation<br>up to ~5000]
    A --> AC[Accounts per Operation<br>up to ~1500]
    A --> C[Concurrent active Operations<br>several hundreds]

🧭 Use pagination and filters

Endpoints are paginated. Combine pagination with filters to reduce payload sizes and render times.

  • Operations list (admin) GET /admin/operations Filters available: status, operationId, operationName.
  • Lines GET /admin/operations/{id}/lines Filters available: variantExternalId, variantName.
  • Accounts (PRIVATE) GET /admin/operations/{id}/accounts Filters available: operationStatus, accountName, accountId, userId, email.
graph TD
    L[List page] --> R[GET list with filters]
    R --> P{Page has next token}
    P -- Yes --> N[GET next page]
    P -- No  --> D[Done]

In the UI, prefer incremental loading with a visible page size, and enable search on the server. For tables of 1k rows or more, add virtualized scrolling on the client.

🧩 Batch operations

Use batch endpoints to reduce roundtrips:

  • Lines: PUT /admin/operations/{id}/lines updates multiple lines in one call.
  • Lines deletion: DELETE /admin/operations/{id}/lines accepts a list of product variant ids.
  • Accounts: POST and DELETE /admin/operations/{id}/accounts accept lists.

Keep payloads reasonably sized to maintain snappy admin UX. Split very large batches if needed.

🔒 Concurrency, locking and safety

  • Lines and accounts are editable only in DRAFT. This protects carts and orders created from ACTIVE Operations.
  • Avoid changing dates in ACTIVE unless required for the campaign.
  • Deleting an Operation is blocked if any cart or order is linked.

🧠 Frontend UX tips

  • Use skeletons or loading states while fetching pages.
  • Sort by code or name to help operators find Operations quickly.
  • Add client-side selection buffers when building partial carts orders from large Operations.
  • Use locales efficiently: request a single locale for front DTOs and keep admin DTOs multilingual when editing copy.

🧪 Heavy comparisons and reporting

If you need to compare an order with an Operation, prefer a server-driven approach rather than downloading all lines to the browser for large Operations. Reuse admin filters to scope the comparison set when possible.

🔗 API quicklinks

Required headers (Admin)

  • dj-client: OPERATOR (or ACCOUNT for authorized admin actions)
  • dj-api-key: your key
  • dj-store, dj-store-view (optional; store scoping)
  • locale (optional; localized fields)

High-volume list endpoints (use filters + pagination)

Batch endpoints (reduce round-trips)

Concurrency & safety (what impacts performance)

  • Lines and account attachments are editable only in DRAFT to protect carts/orders once the Operation is ACTIVE/INACTIVE.
  • Avoid heavy client-side diffs; prefer server-side comparisons for large Operations.

Deletion constraints

Tip: For very large datasets, apply filters first, then page through results. Use sort to stabilize pagination order, and keep batch payloads to a practical size to maintain a responsive admin UX.

Updated 17 days ago