- Introduction of API Version 2 to support improved structure and breaking changes.
- Added missing localization fields to enhance multilingual support.
- Prevented unintended updates to Sender fields from the receiver side.
Sender is now allowed to update the following fields:
SubjectReturnInvoiceNoDeliveryNoteNumber
- Modified request structure: it now returns options per flow type instead of per claim category.
- Added culture information to provide more concise responses with translated descriptions.
¶ Affected in Both V1 and V2
- Corrected issue where problem packing conditions were not updating correctly.
- Updated garage salutation type from
string to int, using enum values.
SenderInternalNotes → SenderInternalNotePackagingCondition → PackagingConditions
¶ Both Versions 1 and 2 – Update 25.11.2025
The method GetReceiverShippingLabelSettings have been extended to support pick-up service functionality with the following new properties:
IsUsePickupServiceIsPickupLocationRequired
Important Rule:
When IsUsePickupService = true and IsPickupLocationRequired = true, the system enforces that every newly created claim must provide a valid PickupLocation; otherwise, the claim is rejected as invalid.
The Claim model has been extended with a new field:
¶ Both Versions 1 and 2 – Update 04.12.2025
- Added a new endpoint allowing the claim receiver to reopen a claim and update the claim decision.
- A message is required when reopening a claim.
- The message is visible to the sender in the claim history.
¶ Both Versions 1 and 2 – Update 11.12.2025
¶ New Dispute Handling Process
The dispute resolution workflow has been significantly updated:
Previous Flow:
- Sender creates dispute
- Receiver could directly update decision while claim is disputed
- Receiver resolves dispute (accept/reject) with optional comments
- Single-step resolution process
Current Flow:
- Sender creates dispute
- Receiver must first choose an action:
- Take Into Work: Puts claim and dispute into "in work" status, allowing preparation of new decision
- Reject: Immediately resolves dispute and returns claim to "Decided" status
- If taken into work, receiver submits new decision to resolve dispute
- Two-step resolution process for accepted disputes
Replaced Endpoints:
PUT api/v2/disputes/{TecComId}/resolve
New Endpoints:
PUT api/v1/disputes/{tecComId}/take-into-work/{claimId} - Accepts dispute for processingPUT api/v1/disputes/{tecComId}/reject/{claimId} - Rejects dispute immediately
Updated Endpoints:
POST api/v1/disputes/{tecComId} - Create dispute (updated from v2)PUT api/v1/claims/submit-decision/{tecComId}/{culture} - Now resolves disputes when in "in work" status
¶ New Request Body Fields
disputeComment field added to DecisionRequestDto (optional)
- Used when submitting decision to resolve a dispute that was taken into work
- Allows receiver to provide context when resolving dispute
- PickupInitiated status (value = 7) - Introduced for claim parts
- PartsReceived status (value = 5) - Updated status handling
- The
disputeComment field in submit-decision is optional but recommended for dispute resolution
- Cannot set decision to "None" during dispute processing
- Dispute resolution now requires explicit receiver action (take-into-work or reject)
- Auto-generates chat messages and notifications at each step
- Dispute level increases with each new dispute until maximum level reached