Engineering inside ReturnPath /

Interface and interaction architecture

XState represents the current saved lifecycle and permitted next steps. Server-side policy and quantity checks remain authoritative for real actions.

Availability accounts for other active cases

A line's available quantity is its fulfilled quantity minus units already returned and units reserved by other authorised cases. Eligibility is recalculated at approval and authorisation. This prevents two operators from relying on the same stale availability figure when reviewing separate requests for the same line.

Time limits are checked when an action occurs

The stored policy version defines the return deadline. A case approval expires at the earlier of that deadline or twenty-four hours after approval. Authorisation reads the current time rather than assuming a previously displayed eligible state is still valid. Expiry is a business precondition, not a visual countdown alone.

Receipt is a coordinated state change

Workspace mutations use revision-based serialisation and bounded retry. Receipt changes the order's returned quantity and case status atomically, while cancellation releases an authorisation without pretending an item arrived. Version checks prevent an older screen from silently overwriting a newer decision.

Retries preserve the original action

Workspace-scoped idempotency records capture the actor, endpoint and payload. Replaying the same receipt returns its saved result even after the case has advanced, rather than incrementing the quantity twice. Workspace-scoped references also prevent a case from pointing to another workspace's order or policy. Unavailable carrier actions return an explicit provider error.

Operating the product

Start with the public interface preview to explore overview and insights using example records. Open /dashboard for account-scoped metrics calculated from your saved records, or /desk for the underlying workflow.

Use stable order-line identifiers and preserve the policy version associated with a decision. If source data is wrong, resolve it through an explicit operational process; an incorrect fulfilled quantity can undermine otherwise correct availability arithmetic.

When authorisation fails after approval, inspect the current evidence. Another case may have reserved the remaining units, or the approval or policy window may have expired. Do not bypass the rejection by changing identifiers or repeatedly creating new cases.

After an uncertain receipt response, retry the identical command with its original operation key and reload the order. Creating a fresh receipt command before checking the recorded result risks confusing a transport problem with a business action that already completed.

Record receipt only after a responsible person has checked the goods. Authorised, received and refunded are different operating facts; ReturnPath's local receipt should not be used as proof that a refund or inventory disposition occurred elsewhere.

A cancelled authorisation makes its reserved units available again. Review that consequence before cancellation, especially when support and warehouse staff are handling the same order through different channels.

Independent by construction

ReturnPath has its own application source, build configuration, local server, database, object store and session cookie. The fifteen applications reuse copies of a common foundation, but their operational data and credentials are independent. A shared dependency cache on this Mac saves disk space; each product includes a lockfile and a command to install its own dependencies.

Mutations validate the workspace and current record version. Approval binds the reviewed content digest; an idempotency key prevents an identical retry from becoming a second action. These controls are implemented in the server, alongside the product-specific rules described above.