Search in documentation

Modules

Authentication

Merchant

Catalog

Order

Events

Logistics

Shipping

Review

Financial

Solutions

Orders outside iFood platform

Use this documentation to integrate orders created in external systems (without pre-existing orderId) with iFood's On Demand delivery service. Ideal for integrators who manage their own order systems and want to contract iFood's logistics services.

How it works

The flow consists of 5 main stages:

Check availability - Validate coverage and get quote
Register order - Create the order and allocate driver
Manage address - Confirm or change delivery address
Cancel order - Cancel as needed
Monitor trust level - Track delivery security level

1. Check availability

Check delivery availability to validate coverage, obtain price, and estimated time.

Why check?

This stage is essential for:

Validating that the address is within iFood coverage area
Identifying temporary unavailability (high demand, off-hours)
Obtaining price information (gross, discount, surcharge) and estimated time
Avoiding failures in order creation
Better planning of preparation time

We recommend performing this check to improve success rate and user experience.

Endpoint

GET /shipping/v1.0/merchants/{merchantId}/deliveryAvailabilities?latitude={lat}&longitude={lng}

Parameters

Parameter	Location	Type	Required	Description
`merchantId`	path	uuid	Yes	Merchant ID (your store)
`latitude`	query	float	Yes	Latitude of delivery address (ex: -23.55)
`longitude`	query	float	Yes	Longitude of delivery address (ex: -46.63)

Example request

curl -X GET "https://merchant-api.ifood.com.br/shipping/v1.0/merchants/{merchantId}/deliveryAvailabilities?latitude=-23.5505&longitude=-46.6333" \
  -H "Authorization: Bearer YOUR_JWT_TOKEN" \
  -H "Content-Type: application/json"

Success response - 200 OK

Valid quote obtained successfully. Use the returned id as quoteId when registering the order.

Response fields

Field	Type	Description
`id`	uuid	Quote ID (use as `quoteId` when creating order)
`expirationAt`	datetime	Quote validity in UTC (~24h). Requesting after is invalid.
`createdAt`	datetime	Quote creation date in UTC
`distance`	integer	Delivery distance in meters
`preparationTime`	integer	Suggested preparation time in seconds
`quote.grossValue`	decimal	Gross delivery value in reals
`quote.discount`	decimal	Applied discount in reals
`quote.raise`	decimal	Applied surcharge in reals
`quote.netValue`	decimal	Net value = grossValue - discount + raise
`deliveryTime.min`	integer	Estimated minimum delivery time in seconds
`deliveryTime.max`	integer	Estimated maximum delivery time in seconds
`hasPaymentMethods`	boolean	Indicates if payment methods are available
`paymentMethods[].id`	uuid	Unique payment method ID
`paymentMethods[].brand`	string	Card brand (ex: Visa, Mastercard)
`paymentMethods[].liability`	string	Payment responsible party (ex: IFOOD)
`paymentMethods[].paymentType`	string	Payment type (ex: OFFLINE for cash on delivery)
`paymentMethods[].method`	string	Payment method: CREDIT, DEBIT or CASH

Example response

{
  "id": "57cd1046-2e06-446f-a2dd-18a518212c3c",
  "expirationAt": "2023-08-18T19:49:06Z",
  "createdAt": "2023-08-17T19:49:06Z",
  "distance": 3000,
  "preparationTime": 60,
  "quote": {
    "grossValue": 7.99,
    "discount": 0,
    "raise": 0,
    "netValue": 7.99
  },
  "deliveryTime": {
    "min": 1200,
    "max": 1800
  },
  "hasPaymentMethods": true,
  "paymentMethods": [
    {
      "id": "21c65a8c-f29e-463f-b0bd-240edeb593c4",
      "brand": "Visa",
      "liability": "IFOOD",
      "paymentType": "OFFLINE",
      "method": "CREDIT"
    },
    {
      "id": "93c1c7c7-61f1-4dd9-bb84-62a03254701d",
      "liability": "IFOOD",
      "paymentType": "OFFLINE",
      "method": "CASH"
    }
  ]
}

Interpreting the response:

Distance: 3 km
Price: R$ 7.99 (no discount or surcharge)
Estimated time: 20-30 minutes
Payment methods: Visa card or Cash available

Errors - 400 Bad Request

The API returns 400 Bad Request when delivery is not available. Check the error codes to determine the cause.

For detailed solutions for each error, consult Best practices and troubleshooting.

Error codes

Code	Description	Recommended Action
BadRequest	Problem in request	Verify if `latitude` and `longitude` are in correct format
BadRequestMerchant	Your store is temporarily unavailable	Check store status in dashboard
DeliveryDistanceTooHigh	Address more than ~10 km from store	Confirm coordinates with customer
OffOpeningHours	Outside logistics operating hours	Try again during business hours
OriginNotFound	Store not found in logistics area	Register your store in iFood areas
ServiceAreaMismatch	Address outside iFood coverage	Confirm if region has iFood delivery
HighDemand	Logistics saturated temporarily	Try again in a few minutes
MerchantStatusAvailability	Your account has pending issues	Contact iFood support
InvalidPaymentMethods	Payment method not supported	Use another payment method
NRELimitExceeded	Limit of simultaneous drivers reached	Wait for ongoing deliveries to complete
UnavailableFleet	Driver fleet unavailable	Try again later

Internal error - 500 Internal Server Error

Temporary server error. Try again in a few seconds.What to do: Implement automatic retry with exponential backoff. After 3-5 failed attempts, log and notify support.

2. Register order

Important behavior

Understand how the system works:

A driver is allocated automatically after successful registration
If delivery is not viable, the order will not be created
Validate all data before sending to avoid rejections
Registration is an asynchronous operation; use the returned id for tracking

Delivery security: Confirmation code

For security, a confirmation code is automatically generated. The driver will request this code from the customer to validate identity.

Two modes available

Mode 1: With code (default - recommended)

Send customer.phone.type="CUSTOMER" with valid number
The code will be the last 4 digits of the phone
Driver will request the code before delivery
More secure; recommended for high-value deliveries

Mode 2: Without code (authorization only)

Send customer.phone.type="STORE"
Code will not be requested
Presence validation only
Use when customer cannot provide validation

Inform the customer

Inform the customer in advance that the driver will request validation (code or confirmation). Failure or refusal may result in cancellation without refund.

For integrators without iFood tracking page

If your platform does not use iFood's tracking page, implement:

Listen for the event DELIVERY_DROP_CODE_REQUESTED
Extract the code from metadata.CODE of the event
Display to customer via SMS, email or app
Communicate with driver to request validation

Flow: Monitor events → Extract code → Notify customer → Driver validates

Endpoint

POST /shipping/v1.0/merchants/{merchantId}/orders

Example request

curl -X POST "https://merchant-api.ifood.com.br/shipping/v1.0/merchants/{merchantId}/orders" \
  -H "Authorization: Bearer YOUR_JWT_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "customer": {
      "name": "João Silva",
      "phone": {
        "countryCode": "55",
        "areaCode": "11",
        "number": "999999999",
        "type": "CUSTOMER"
      }
    },
    "delivery": {
      "merchantFee": 5.99,
      "quoteId": "57cd1046-2e06-446f-a2dd-18a518212c3c",
      "deliveryAddress": {
        "postalCode": "01310100",
        "streetNumber": "100",
        "streetName": "Avenida Paulista",
        "neighborhood": "Bela Vista",
        "city": "São Paulo",
        "state": "SP",
        "country": "BR",
        "coordinates": {
          "latitude": -23.5505,
          "longitude": -46.6333
        }
      }
    },
    "items": [{
      "id": "item-1",
      "name": "Hambúrguer",
      "quantity": 1,
      "unitPrice": 25.00,
      "price": 25.00,
      "optionsPrice": 0,
      "totalPrice": 25.00
    }],
    "payments": {
      "methods": [{
        "method": "CREDIT",
        "type": "OFFLINE",
        "value": 30.99,
        "card": {
          "brand": "Visa"
        }
      }]
    }
  }'

Response - 202 Accepted

Order created successfully. A driver is being allocated.

{
  "id": "522e4d7e-0ce1-44f3-8cc7-73a9f190a5e8",
  "trackingUrl": "https://meupedido.ifood.com.br/522e4d7e-0ce1-44f3-8cc7-73a9f190a5e8"
}

Returned fields:

id (uuid) - Unique order ID created (use for future operations)
trackingUrl (string) - Tracking URL shareable with customer

Next actions:

Share the trackingUrl with customer to track delivery
Monitor delivery events by polling with the returned id
Implement listeners for events like DELIVERY_DROP_CODE_REQUESTED, DELIVERY_IN_TRANSIT, DELIVERY_CONCLUDED

Order fields

Required fields marked with *

Customer

Field	Type	Description
`customer.name`*	string	Name (max. 50 characters)
`customer.phone.type`	string	CUSTOMER (default) or STORE
`customer.phone.countryCode`*	string	Country code (2 digits). Ex: 55
`customer.phone.areaCode`*	string	Area code (2 digits). Ex: 11
`customer.phone.number`*	string	Phone (7-9 digits)

* Not required if customer.phone.type="STORE"

Delivery

Field	Type	Description
`delivery.merchantFee`*	float	Partner fee
`delivery.preparationTime`	integer	Preparation time (seconds)
`delivery.quoteId`	uuid	Quote ID
`delivery.deliveryAddress.postalCode`*	string	Postal code (8 digits)
`delivery.deliveryAddress.streetNumber`*	string	Street number
`delivery.deliveryAddress.streetName`*	string	Street name (max. 50 characters)
`delivery.deliveryAddress.complement`	string	Complement (max. 50 characters)
`delivery.deliveryAddress.reference`	string	Reference (max. 70 characters)
`delivery.deliveryAddress.neighborhood`*	string	Neighborhood (max. 50 characters)
`delivery.deliveryAddress.city`*	string	City (2-50 characters)
`delivery.deliveryAddress.state`*	string	State (2 letters). Ex: SP
`delivery.deliveryAddress.country`*	string	Country (2 letters). Ex: BR
`delivery.deliveryAddress.coordinates.latitude`*	float	Latitude
`delivery.deliveryAddress.coordinates.longitude`*	float	Longitude

Items

Field	Type	Description
`items[].id`*	uuid	Item ID
`items[].name`*	string	Name (max. 50 characters)
`items[].externalCode`	string	External code
`items[].quantity`*	integer	Quantity (> 0)
`items[].unitPrice`*	float	Unit price (≥ 0)
`items[].price`*	float	Total price (quantity * unitPrice)
`items[].optionsPrice`*	float	Add-ons price (≥ 0)
`items[].totalPrice`*	float	Total (price + optionsPrice)

Payments

Offline Payment:

Field	Type	Description
`payments.methods[].method`*	string	CREDIT, DEBIT or CASH
`payments.methods[].type`*	string	OFFLINE
`payments.methods[].value`*	float	Amount
`payments.methods[].card.brand`*	string	Brand (if CREDIT/DEBIT)
`payments.methods[].cash.changeFor`*	float	Change (if CASH)

Online Payment: Do not send payments object (processed by merchant)

Other fields

Field	Type	Description
`displayId`	string	Friendly ID (max. 4 characters). Ex: A4BC
`metadata`	object	Additional information (max. 20 characters)

Preparation time

The delivery.preparationTime parameter (in seconds) controls when the driver will be allocated. This is critical for customer experience.

Why preparation time matters

Incorrect timing results in serious operational issues:

Scenario	Problem	Impact
Too short	Driver arrives before order is ready	Customer waits, driver idle
Too long	Driver waits without purpose	Queue congestion, inefficient allocation
Correct	Driver and order ready simultaneously	Optimal operation, satisfied customer

How to use

Option 1: Immediate allocation (default)

{
  "delivery": {
    // Do not send preparationTime or send 0
  }
}

→ Driver allocated immediatelyOption 2: Delayed allocation (recommended)

{
  "delivery": {
    "preparationTime": 900  // 15 minutes in seconds
  }
}

→ Driver allocated after 15 minutes

Best practices

Use real data: Base preparationTime on your average preparation time
Check the quote: The availability endpoint returns suggested preparationTime - use as reference
Adjust iteratively: Monitor if drivers arrive early/late and adjust
Add buffer: Consider peaks - it's better to deliver slightly late than lose orders

Practical example

Your business data:
- Average preparation time: 12 minutes
- Typical variation: ±2 minutes
- Safety margin: +3 minutes

Recommendation:
preparationTime = (12 + 3) * 60 = 900 seconds (15 minutes)

Event polling integration

After successfully creating the order, implement event monitoring:

Source: Event polling
Filter: Orders with salesChannel="POS" (use the returned id)
Critical events:
- DELIVERY_DROP_CODE_REQUESTED - Confirmation code needed
- DELIVERY_IN_TRANSIT - Driver left for delivery
- DELIVERY_CONCLUDED - Delivery completed
- DELIVERY_CANCELLED - Delivery cancelled
Tracking: Use the order id at tracking endpoint to get location

Errors - 400 Bad Request

Invalid request or service unavailable.

For detailed solutions for each error, consult Best practices and troubleshooting.

Code	Description	Recommended Action
BadRequest	Invalid data in request	Verify all required fields (marked with *)
BadRequestCustomer	Customer unavailable or invalid	Check customer name, phone
BadRequestMerchant	Your store is unavailable	Check store status in dashboard
DeliveryDistanceTooHigh	Address outside coverage	Confirm coordinates with customer
HighDemand	Logistics saturated now	Try again in a few minutes
MerchantEasyDeliveryDisabled	Service not enabled for your store	Enable service in iFood dashboard
OffOpeningHours	Outside operating hours	Wait for business hours
OriginNotFound	Store not located in logistics area	Register your store in iFood areas
PaymentMethodNotFound	Payment method not supported	Use available method (CREDIT, DEBIT or CASH)
PaymentTotalInvalid	Payment amount ≠ order total	Verify sum of items + delivery
ServiceAreaMismatch	Address outside service area	Confirm iFood coverage in region
NRELimitExceeded	Limit of simultaneous drivers	Wait for ongoing deliveries to complete

Internal error - 500 Internal Server Error

Temporary server error. Try again in a few seconds.What to do: Implement retry with exponential backoff. After 3-5 failed attempts, log and notify support.

3. Confirm/change address

Manage address changes after the order is created. Customers can confirm the address or request a change.

Two flows available

Option A: With iFood tracking page (recommended)

Customer uses iFood's page (trackingUrl) to confirm/change address securely.Requirements:

Order cannot have customer.phone.type="STORE"
Valid phone is required (receives OTP via SMS)
Use URL returned on order creation

Flow: Customer accesses URL → Receives OTP via SMS → Validates address → ConfirmsAdvantage: iFood manages security, OTP, validation

Option B: Without iFood tracking page (custom integration)

Your platform implements your own confirmation/change interface using the endpoints.Requirements:

You manage the user interface
Your responsibility to validate and implement security

Flow: Customer confirms in your app → You call endpoints → Monitor eventsNote: iFood does not send OTP. You choose how to validate (password, custom OTP, etc).

Security: If you use OTP, implement proper validation. Incorrect addresses result in delivery failures.

3.1 Confirm original address

Used when customer confirms the provided address is correct (no changes).

POST /shipping/v1.0/orders/{orderId}/userConfirmAddress

Example request

curl -X POST "https://merchant-api.ifood.com.br/shipping/v1.0/orders/{orderId}/userConfirmAddress" \
  -H "Authorization: Bearer YOUR_JWT_TOKEN" \
  -H "Content-Type: application/json"

Response - 202 Accepted

Confirmation registered successfully.Event generated: DELIVERY_ADDRESS_CHANGE_USER_CONFIRMEDMonitor this event to be notified when customer confirms.

3.2 Request address change

Customer can request to change delivery address after order creation (maximum 500m from original coordinate).

POST /shipping/v1.0/orders/{orderId}/deliveryAddressChangeRequest

Parameters

Parameter	Type	Required	Description
`streetNumber`	string	No	Street number (ex: 200)
`streetName`	string	Yes	Street name (ex: Flower Street)
`complement`	string	No	Complement (ex: Apt 42)
`neighborhood`	string	Yes	Neighborhood (ex: Center)
`city`	string	Yes	City (ex: São Paulo)
`state`	string	Yes	State (ex: SP, 2 letters)
`country`	string	Yes	Country (ex: BR, 2 letters)
`reference`	string	No	Reference (ex: Near the station)
`coordinates.latitude`	float	Yes	Latitude of new address
`coordinates.longitude`	float	Yes	Longitude of new address

Example request

curl -X POST "https://merchant-api.ifood.com.br/shipping/v1.0/orders/{orderId}/deliveryAddressChangeRequest" \
  -H "Authorization: Bearer YOUR_JWT_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "streetNumber": "200",
    "streetName": "Rua das Flores",
    "complement": "Apto 42",
    "neighborhood": "Centro",
    "city": "São Paulo",
    "state": "SP",
    "country": "BR",
    "reference": "Perto da estação",
    "coordinates": {
      "latitude": -23.5510,
      "longitude": -46.6340
    }
  }'

Response - 202 Accepted

Change request registered. Your system must respond within 15 minutes.Event generated: DELIVERY_ADDRESS_CHANGE_REQUESTEDMonitor this event to be notified of the request and offer options to the customer.

Important restrictions

Restriction	Limit	Consequence
Maximum distance	500m from original coordinate	Changes larger are rejected
Response deadline	15 minutes	After that, automatic rejection
Region change	Not allowed	Generates automatic denial event

3.3 Accept address change

Your system approves the address change requested by the customer.

POST /shipping/v1.0/orders/{orderId}/acceptDeliveryAddressChange

Example request

curl -X POST "https://merchant-api.ifood.com.br/shipping/v1.0/orders/{orderId}/acceptDeliveryAddressChange" \
  -H "Authorization: Bearer YOUR_JWT_TOKEN" \
  -H "Content-Type: application/json"

Response - 200 OK

Change accepted successfully.Event generated: DELIVERY_ADDRESS_CHANGE_ACCEPTEDSpecial note: If the new address falls in another region, iFood automatically denies with event DELIVERY_ADDRESS_CHANGE_DENIED and metadata.action="region-mismatch".

3.4 Deny address change

Your system denies the address change requested (when not viable, for example).

POST /shipping/v1.0/orders/{orderId}/denyDeliveryAddressChange

Example request

curl -X POST "https://merchant-api.ifood.com.br/shipping/v1.0/orders/{orderId}/denyDeliveryAddressChange" \
  -H "Authorization: Bearer YOUR_JWT_TOKEN" \
  -H "Content-Type: application/json"

Response - 202 Accepted

Denial registered successfully.Event generated: DELIVERY_ADDRESS_CHANGE_DENIED

Common errors in address change

Code	Status	Description	Action
BadRequest	400	Invalid parameters	Check coordinates, street name, city
OrderNotFound	404	Order not found or expired (>8h)	Order is valid for up to 8 hours
ChangeAddressOperationConflict	409	Operation in conflict	Another change already pending
ChangeAddressOperationNotStarted	409	No pending change	No request to accept/deny
MaxDistanceHigherThanAllowed	400	Change > 500m from original coordinate	Request outside allowed limit
RegionMismatch	400	New address in different region	Address in different iFood coverage

4. Cancellation

Cancel orders created outside the platform (salesChannel="POS"). The process is in two stages: get valid reasons and send cancellation.

4.1 Get available cancellation codes

Before canceling, check valid reasons. You cannot hardcode reasons.

GET /shipping/v1.0/orders/{orderId}/cancellationReasons

Example request

curl -X GET "https://merchant-api.ifood.com.br/shipping/v1.0/orders/{orderId}/cancellationReasons" \
  -H "Authorization: Bearer YOUR_JWT_TOKEN" \
  -H "Content-Type: application/json"

Response - 200 OK

List of valid reasons for this specific order.

[
  {
    "cancelCodeId": "817",
    "description": "Customer cancelled the order"
  },
  {
    "cancelCodeId": "818",
    "description": "Unable to prepare order"
  }
]

Fields:

cancelCodeId (string) - Unique reason code (use in cancellation)
description (string) - Readable description to show operator

Response - 204 No Content

Order cannot be cancelled (already delivered, cancelled, etc). No action needed.

4.2 Cancel the order

After getting valid reasons, send cancellation with code and reason.

POST /shipping/v1.0/orders/{orderId}/cancel

Parameters

Field	Type	Required	Description
`reason`	string	Yes	Explanatory text for cancellation (for logs)
`cancellationCode`	integer	Yes	Code obtained in 4.1 (ex: 817)

Example request

curl -X POST "https://merchant-api.ifood.com.br/shipping/v1.0/orders/{orderId}/cancel" \
  -H "Authorization: Bearer YOUR_JWT_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "reason": "Customer requested cancellation via chat",
    "cancellationCode": 817
  }'

Body:

{
  "reason": "Customer requested cancellation via chat",
  "cancellationCode": 817
}

Response - 202 Accepted

Cancellation registered. Monitor events for confirmation.Event sequence:

CANCELLATION_REQUESTED - Cancellation requested
CANCELLED - Cancellation confirmed successfully
CANCELLATION_REQUEST_FAILED - Cancellation failed (ex: driver already left)

Monitor by polling to know final result.

5. Delivery trust level (Safe Delivery Score)

Automatic scoring system that calculates the trust level of each delivery based on customer and address validation factors.Use the score for: Making operational decisions (ex: request extra confirmation for LOW, prioritize HIGH/VERY_HIGH).

Trust levels

Level	Description	When it occurs	Recommendation
LOW	Low trust	Invalid customer or change denied	Request extra customer confirmation
MODERATE	Moderate trust	Landline phone (weaker validation)	Monitor carefully
HIGH	High trust	Valid mobile phone	Standard processing
VERY_HIGH	Very high trust	Valid phone + address confirmed	Prioritize, lower risk

Calculation rules

The score is calculated by combining the following factors:

Rule	Description	Impact
customer_phone_valid	Valid mobile phone (11+ digits, type CUSTOMER)	Increases trust
customer_phone_is_fixed	Landline phone (8 digits)	Intermediate trust
customer_address_confirmed	Customer confirmed address	Increases much
customer_address_change_requested	Customer requested address change	Reduces (may indicate initial error)
merchant_address_change_approved	You approved change	Improves score
merchant_address_change_denied	You denied change	Reduces significantly

Scoring examples

Scenario 1: No validation
`customer_phone_valid`=false
→ Score: LOW (high risk)

Scenario 2: Landline phone only
`customer_phone_is_fixed`=true
→ Score: MODERATE

Scenario 3: Valid mobile phone
`customer_phone_valid`=true
→ Score: HIGH

Scenario 4: Phone + Address confirmed
`customer_phone_valid`=true +
`customer_address_confirmed`=true
→ Score: VERY_HIGH (maximum trust)

Scenario 5: Change approved
`customer_phone_valid`=true +
`merchant_address_change_approved`=true
→ Score: VERY_HIGH

Scenario 6: Change denied
`customer_phone_valid`=true +
`customer_address_change_requested`=true +
`merchant_address_change_denied`=true
→ Score: LOW (distrust)

Check trust level

GET /shipping/v1.0/orders/{orderId}/safeDelivery

Example request

curl -X GET "https://merchant-api.ifood.com.br/shipping/v1.0/orders/{orderId}/safeDelivery" \
  -H "Authorization: Bearer YOUR_JWT_TOKEN" \
  -H "Content-Type: application/json"

Response - 200 OK

Score calculated with details of evaluated rules.

{
  "rules": {
    "customer_address_change_requested": false,
    "customer_address_confirmed": true,
    "customer_phone_is_fixed": false,
    "customer_phone_valid": true,
    "merchant_address_change_approved": false,
    "merchant_address_change_denied": false
  },
  "score": "VERY_HIGH"
}

Interpretation:

Customer has valid mobile phone ✓
Customer confirmed address ✓
No pending changes ✓
Score = VERY_HIGH (maximum trust)

Fields:

score (enum) - Level: LOW, MODERATE, HIGH, VERY_HIGH
rules.* (boolean) - Each rule true or false

Response - 400 OrderWithoutSafeDelivery

Order without applicable trust rules (created before system).

Response - 404 OrderNotFound

Order does not exist or expired (maximum 8 hours).

Score dynamics

The score is not static - it changes as actions occur:

When score changes

Event	Impact	New Score
Customer confirms address	Increases trust	Can rise to VERY_HIGH
Customer requests change	Reduces (initial error?)	Can drop to MODERATE/LOW
You approve change	Increases trust	Can return to VERY_HIGH
You deny change	Reduces much	Falls to LOW
Time passes	Some data expires	Score can drop over time

Best practice

Check the score near delivery time (not just on creation):

1. Order created → Score HIGH
   ↓ (Customer confirms address)
2. Before delivery → Score VERY_HIGH
   ↓ (Use for critical decisions)
3. Allocate resources or apply extra validations if LOW

Operational usage example:

Score VERY_HIGH → Standard delivery, no extra validation
Score HIGH → Normal monitoring
Score MODERATE → Consider advance customer contact
Score LOW → Require extra confirmation before delivery

Next steps

Integration complete?

Implement event polling to monitor deliveries in real-time
Check the delivery tracking guide for real-time location
Review the complete order flow to understand lifecycle

Ready for production?

Test all scenarios (success, failure, cancellation, address change)
Implement alerts and error monitoring
Configure automatic retry with exponential backoff
Prepare internal documentation and operator training

Questions?

Explore the complete API reference
Check the shipping technical documentation
Contact support

Was this page helpful?

Rate your experience in the new Developer portal: