Rules of engagement

The legacy SOAP Custom Link encodes several operational rules that aren’t obvious from the XML schema alone — some enforced by the server, some conventions that avoid support escalations or data loss. Read this page before building against any Custom Link command.

Retrieve before you update

Orders — enforced. Storing changes to an existing order that wasn’t fetched via RequestOrdersNormal first is rejected by the server. New orders (negative Id) are exempt — only updates to existing orders require the prior fetch. Always: retrieve the full order, edit the XML, resend the full edited structure. Omitted fields are cleared, not left unchanged, because a store call replaces the whole record.

Everything else (clients, employees, rides, hours, traces) — not enforced, but still recommended. The server does not reject stores to records that weren’t fetched first for these entities — it updates the database row directly. However, store calls still replace the full record, so fields you omit may still be cleared. Fetch → edit → resend remains the safest pattern even though the server won’t stop you from skipping it.

See Order update for the full retrieve-then-store walkthrough.

Store one entity per call

The schema technically allows small batches (TEoOrderMxList accepts up to 50 items), but the operational convention is one order per StoreOrdersNormal call. Submitting multiple orders in a single call triggers an internal support notification on the MendriX side asking the integrator to switch to one-per-request. Retrieval may be batched; storing should not be.

Apply the same one-at-a-time discipline to other store commands unless a command’s own documentation shows multiple items per call (for example, StoreTracesGoods and StoreMeasurements do support small multi-item batches in their published examples).

Poll incrementally with Sequence

Every order-Ids response (ResponseOrdersNormalIds) carries a SequenceMaximum. Pass SequenceMinimum (one higher than the last SequenceMaximum you saw) on your next poll to get back only the orders that changed since — instead of re-requesting and diffing the full result set yourself.

Sequence is assigned synchronously

As of a 2026 rework, Sequence is assigned synchronously — in the same database statement that performs the store. There is no background-process lag (this replaced an older architecture where a separate background job updated Sequence asynchronously; that mechanism no longer exists).

IgnShowAlways is unrelated to Sequence filtering — SequenceMinimum/ SequenceMaximum are always applied regardless of this flag. IgnShowAlways only controls whether always-visible (ShowAlways) orders bypass the period/client/operator filters; it should normally be set True for retrieval (default is False). See Order retrieval & sync for a full worked example.

Don’t hammer the server

This is an explicit MendriX guideline, not just courtesy: spread load by requesting/storing in small portions (per day, per hour, per order) rather than large batches in one call, and leave idle time between polls. Measure server load and response time for your specific tenant and back off if requests start slowing down.

Security is scoped to how you connect

Custom Link’s raw TCP/IP socket protocol has no built-in authentication — it trusts localhost by design and must never be exposed externally. The SOAP path this portal documents is the correct way to integrate from outside the network: it requires a TAuthenticationHeader (SOAP name/password or API token) and runs over TLS. See SOAP overview & connection for the envelope and header details.

Client-scoped API tokens can only call a fixed allowlist of commands — anything else returns Security: no permission for request <RequestClassName> (for example, Security: no permission for request TEoCustomLinkStoreEmployees). See the Command reference for which commands are on that list.

The 2026-2 order period-matching change

Filtering orders by period (PeriodBegin/PeriodEnd in RequestOrdersNormalIds) changed in MendriX 2026.2: orders are now matched by window overlap (any task active at any point in the period) instead of the old point-in-period matching (a task moment falling inside the period). This returns more orders than before for windows that straddle the period boundary.

A compatibility flag, UseLegacyOrderFilterPeriodMatching, restores the old behavior per-request or installation-wide:

<Filter Type="TEoFilterOrdersNormal">
  <PeriodBegin>2012-01-01T00:00:00</PeriodBegin>
  <PeriodEnd>2012-01-31T00:00:00</PeriodEnd>
  <ClientNo>110</ClientNo>
  <OperatorId>-1</OperatorId>
  <UseLegacyOrderFilterPeriodMatching>True</UseLegacyOrderFilterPeriodMatching>
</Filter>

Don’t rely on this flag for new integrations — it’s a temporary compatibility aid, not a stable part of the API surface.

Next

• SOAP overview & connection — envelope mechanics and authentication.
• Command reference — every Custom Link command, grouped.
• Order intake, Order update and Order retrieval & sync — the pages where these rules matter most concretely.