Testing

The 3PL API does not use a separate sandbox hostname or company account. Use your provisioned company slug and API key against the production base URL with test: true.

Use any graded or sealed item already available in your live inventory and send it through the normal shipping flow:

1. Validate the destination with /address.
2. Call /rates with an item from your live inventory and test: true.
3. Select a returned courier_id.
4. Call /order with the same shipment data, any unique test value for txHash, and test: true.
5. Check the result through /status as usual.

{
  "address": {
    "name": "Integration Test",
    "email": "developer@example.com",
    "phone": "+1 212 555 0100",
    "address_line_1": "123 Main Street",
    "city": "New York",
    "state": "NY",
    "postal_code": "10001",
    "country_alpha2": "US"
  },
  "certs": [{ "cert": "YOUR_LIVE_INVENTORY_CERT", "value": 100 }],
  "test": true
}

Test Transaction Hash

Test orders do not require a real USDC payment or an on-chain transaction. The txHash can be any unique, non-empty test identifier; it does not need to be a valid blockchain transaction hash or relate to a payment.

{
  "courierId": "courier-service-id-from-rates",
  "txHash": "test-integration-20260803-001",
  "test": true
}

DYLI still uses this value as the order's idempotency key, tracking_key, and /status lookup value. Use a new value for each test shipment, but reuse the same value when retrying the same request.

Test mode skips the live-inventory availability check and does not reduce inventory or record a real sale. It does create a carrier shipment so you can test labels and tracking. Use a deliverable address, prefix the recipient name with your integration name, and cancel unwanted test labels in coordination with DYLI.

For a sealed-product test, replace certs with the normal products request using a live DYLI product id. Vault with DYLI creates and transfers blockchain assets and does not support test mode.

Never send test: true for a customer shipment.