For the complete documentation index, see llms.txt. This page is also available as Markdown.

confirmBaggageLoss

API reference for confirming baggage loss acceptance in OTA Baggage Integration.

💬 Need help? If you're stuck, ask Eva in the Help Center for instant diagnostics.

Ask Eva

Use this endpoint after a 3011 baggage price-change notification. It confirms loss acceptance and allows ticketing to continue.

For the full workflow, see OTA Baggage Integration.

Confirm Baggage Price Change

post

Purpose: Confirm acceptance of the airline baggage price increase for an OTA order that is waiting for baggage price change confirmation.

Prerequisite: The order must have received baggage price change error 3011 and must still be within the configured confirmation period.

Endpoint: https://sandbox.atriptech.com/confirmBaggageLoss.do

The client identity is obtained from the authentication headers. Do not send cid, sub-order number, or a separate confirmation flag in the request body.

Header parameters
AcceptstringRequiredExample: application/json
Content-TypestringRequiredExample: application/json
Accept-EncodingstringRequiredExample: gzip
x-atlas-client-idstringRequiredExample: <YOUR_CLIENT_ID>
x-atlas-client-secretstringRequiredExample: <YOUR_CLIENT_SECRET>
Body
orderNostringRequired

Atlas main order number that is waiting for baggage price change confirmation.

Example: TESTA20260715152149367
Responses
200Success
application/json
statusinteger · enumRequired
  • 0: Confirmation accepted.
  • 336: No pending baggage price change confirmation exists for this order.
  • 337: Confirmation period has expired.
  • 800: Order does not exist.
  • 902: The order does not belong to the authenticated client.
  • 9999: Internal error.
Possible values:
msgstringRequired

It serves as an additional description of the response result. Especially when the interface reports an error (status !=0), it is usually a human-readable error message. Note: Do not use this field in any programming scenarios. For example, do not judge whether the interface responds successfully based on this field. Instead, you should only determine it by checking whether the status is equal to0at any time.

requestIdstring · nullableOptional

Atlas request identifier.

clientRequestIdstring · nullableOptional

Client request identifier, when supplied by the caller.

post/confirmBaggageLoss.do
POST /confirmBaggageLoss.do HTTP/1.1
Accept: text
Accept-Encoding: text
x-atlas-client-id: text
x-atlas-client-secret: text
Content-Type: application/json
Content-Length: 36

{
  "orderNo": "TESTA20260715152149367"
}
200Success
{
  "status": 0,
  "msg": "success"
}

Last updated

Was this helpful?