دسترسی هوشمند به مستندات با MCP (MCP API)

{
  "mcpServers": {
    "digiexpress-api": {
      "url": "https://digiexpress.ir/mcp/api"
    }
  }
}

Use the DigiExpress API documentation MCP. Search and fetch the Authentication section. Explain the exact two-call OTP flow: first POST /api/customers/auth/sendOTP with phone_number, then POST /api/customers/auth/login with username and otp_code. Return the documented success fields and citations. Do not add a refresh endpoint unless it is explicitly documented.

Use only the DigiExpress API documentation MCP. Search and fetch Login with Password, Register with Specified Parcels, Webhook Integration, and Single Label. For a [LANGUAGE/FRAMEWORK] backend, implement this documented flow: POST /api/customers/auth/login; POST /api/v2/shipments with parcels and without max_shipment_capacity_estimation_for_pre_reservation; treat Register HTTP 200 only as queued for asynchronous routing; wait for the successful Webhook before calling GET /api/v2/parcels/{parcel_id_or_code}/label. Preserve every documented request field and cite each fetched section.

Use only the DigiExpress API documentation MCP. Search and fetch Register with Estimated Capacity, Add Parcel, Delete Parcel, Label Generation, and Webhook Integration. Implement the documented [LANGUAGE/FRAMEWORK] flow: register through POST /api/v2/shipments with max_shipment_capacity_estimation_for_pre_reservation and without parcels; treat Register HTTP 200 as asynchronous; after the successful routing Webhook, add each physical package through POST /api/v2/shipments/{shipment_id}/parcels; after Add Parcel returns HTTP 200, retrieve that parcel's label. Enforce remained weight, remained volume, Parcel Size Tier, and the documented delete rules.

Use only the DigiExpress API documentation MCP. Search and fetch the Shipping Time Window section along with Register with Specified Parcels and Register with Estimated Capacity. Implement the documented two-stage [LANGUAGE/FRAMEWORK] flow: query options through POST /api/v2/shipping-time-window-request using cargo_ready_date_time, one origin, one destination, physical estimation, each_parcel_size_tier, and off_day_dates; store the selected option's token and expiry; then register through POST /api/v2/shipments using that token and exactly one of parcels or max_shipment_capacity_estimation_for_pre_reservation. Explain the different Label timing for Specified and Estimated registration. Preserve every documented request field and cite each fetched section.

Search and fetch Webhook Integration Guide and Webhook Feed API. Generate a [LANGUAGE/FRAMEWORK] receiver that accepts DigiExpress POST or PUT events, persists the payload, returns HTTP 200 after successful processing, tolerates unknown fields and Progress Types, and does not require intermediate statuses before a final status such as Delivered. Because DigiExpress currently does not retry a failed Webhook, implement recovery with POST /api/v2/shipments/webhook-feed-request using shipment_ids_or_shipment_consignor_reference_ids. Base every behavior on the fetched documentation and cite it.

I received DigiExpress error code [ERROR_CODE] from [DOCUMENTED_ENDPOINT] for shipment [SYNTHETIC_REFERENCE]. Search by the exact code, endpoint, and related operation; fetch the matching Error Codes and workflow sections; report the documented cause and fix; then verify whether my request fields, Parcel Size Tier, token state, or Shipment state violate that documented flow. Clearly separate documented facts from diagnostic suggestions and never request real credentials or customer data.