/vendor/didi/AgentRouting.json or
/vendor/didi/AgentContext.json directly.
didi.com
Overview
Does didi.com support MCP?
No confirmed MCP support was found for didi.com as of 2026-07-01.
What agentic protocols does didi.com support?
As of 2026-07-01, didi.com has confirmed support for proprietary.
Is didi.com's API publicly accessible or partner-gated?
Partner only.
Does didi.com explicitly prohibit automated access?
Yes. didi.com's terms of service explicitly prohibit automated or scraper access to the public website without prior written permission.
Is didi.com agent-ready?
Partial. didi.com supports some agentic workflows but requires a human handoff for certain operations — see the protocols and summary sections for details.
Protocols
No evidence that DiDi (didi.com) is a participant in, or implementer of, the A2A/Agent2Agent protocol. The original Google launch partners named in official sources include Atlassian, Box, Cohere, Intuit, LangChain, MongoDB, PayPal, Salesforce, SAP, ServiceNow, UKG, and Workday — DiDi is absent from these lists. A targeted search for 'DiDi didi.com Agent2Agent A2A AI agent protocol' returned no vendor-specific results. No confirmed_absent designation is applied because no DiDi-specific statement or deprecation notice was found; the absence is simply a lack of evidence.
No evidence found that DiDi (didi.com) participates in or has adopted the Agentic Commerce Protocol. Named ACP launch and early partners include URBN brands, Coach, Kate Spade, Revolve, Ashley Furniture, Shopify, and Etsy — none of which are DiDi. DiDi is a ride-hailing platform, not a retail merchant, which also makes it a structurally unlikely ACP adopter at this stage given the protocol's current focus on product-catalog-based retail checkout.
No evidence found of DiDi (didi.com) participating in AP2 as a launch partner or subsequent adopter. The confirmed 60+ launch partners named publicly include Mastercard, PayPal, American Express, Adyen, Coinbase, Etsy, Intuit, Revolut, Salesforce, UnionPay International, and Worldpay — DiDi does not appear among them. Neither search returned any DiDi-specific AP2 documentation, announcement, or integration.
No evidence of an official DiDi (didi.com / didiglobal.com) MCP server was found. The third-party article on xugj520.cn describes a 'DiDi MCP' integration, but it is authored by an unofficial site with no link to any vendor-sanctioned MCP endpoint or documentation on didi.com or didiglobal.com — it appears to be a community-written guide rather than anything DiDi itself published. A separate 'Didit' identity-verification company (docs.didit.me) does operate an MCP server but is an entirely unrelated vendor. DiDi's own developer-facing pages (didiglobal.com/contact/platform) reference their open platform SDK but contain no mention of MCP.
No evidence found that DiDi (didi.com) has adopted or implemented MPP. Known MPP launch integrations span model providers, developer tools, and compute services (Cloudflare, MultiversX, etc.) — no ride-hailing or mobility platform appears in published partner lists, and DiDi is not mentioned in any MPP launch coverage. Not confirmed_absent because DiDi has not issued its own statement on MPP; the absence is simply a gap in findable evidence.
No evidence found of didi.com adopting or integrating NLWeb. Named NLWeb pioneers include O'Reilly, Delish, Shopify, Common Sense Media, Chicago Public Media, DDM (Allrecipes & Serious Eats), Milvus, Snowflake, and Inception — didi.com does not appear in any launch partner list. Choosing not_found rather than confirmed_absent because didi.com has never issued a statement specifically declining NLWeb.
No evidence found that DiDi (didi.com), the Chinese ride-hailing and mobility platform, has adopted or integrated the Universal Commerce Protocol. The UCP ecosystem's documented participants and roadmap (covering food, lodging, and retail verticals via Google and Shopify) do not reference DiDi. Multiple targeted searches found no announcements, waitlist enrollment, or technical integration linking didi.com to UCP. Absence of evidence here is not a confirmed denial — DiDi has not issued a statement ruling UCP out, so not_found is the appropriate status rather than confirmed_absent.
No evidence that didi.com has implemented or announced WebMCP support. WebMCP is a nascent browser-native protocol co-developed by Google and Microsoft, currently in early preview; the named early-stage context is around e-commerce and SaaS platforms, with no ride-hailing or DiDi-specific mention in any launch partner or adoption lists found. Not_found rather than confirmed_absent because DiDi has made no vendor-specific statement either way.
No evidence of didi.com (DiDi, the ride-hailing platform) appearing in the x402 ecosystem, launch partner lists, or any x402-related integration announcement. Named participants in the x402 ecosystem include Cloudflare, Google, Vercel, Stellar, Chainlink, and various blockchain-native tooling projects — none of which are DiDi. DiDi is a consumer mobility company with no known public developer API surface aligned with stablecoin micropayment infrastructure.
No evidence of DiDi Global (didi.com) having built or published a ChatGPT app via the OpenAI Apps SDK. Search results found only unrelated entities using the 'DiDi' name (a financial GPT persona, a crypto trading tool), not the ride-hailing company. DiDi's 2025 app overhaul introduced an internal AI assistant, but this is their own product, not a ChatGPT platform integration.
Ride-hailing booking SDK and OpenAPI for third-party app and platform integration; the SDK mode allows embedding a 'hail a DiDi' call-to-action inside partner apps, while the OpenAPI mode covers ride dispatch and user data access but is restricted to invite-only qualified platforms
DiDi's core ride-hailing open platform (滴滴出行开放平台) offers both an SDK integration path and an OpenAPI path; the OpenAPI is explicitly invite-only for qualified platforms while the SDK has broader partner access. Documentation confirms appid/secret-based auth. A companion RMS/Fleet API exists at https://fleet-api.didiglobal.com/developer/rms/ targeting fleet operators and gas station integrations (used under DiDi's 99 brand in Brazil).
Payment processing integration API for merchants accepting DiDi Pay; covers payment initiation, refund, and order query flows for merchant-side checkout
DiDi Pay operates a separate developer portal at didipay.didiglobal.com with its own documentation and integration flow, distinct from the ride-hailing platform. The portal is JavaScript-gated, limiting direct content inspection, but its existence and merchant-payment scope are confirmed by the URL structure and associated references.
Food delivery open platform API for restaurant and logistics partners integrating with DiDi Food (primarily Mexico market); covers order management and delivery coordination
DiDi Food maintains a separate open platform at developer.didi-food.com targeting restaurant and logistics partners in Latin America (Mexico market confirmed). This is structurally and operationally distinct from the core ride-hailing open platform and the DiDi Pay interface. Portal is JS-gated, limiting deeper auth inspection.
Direct HTTP checks for didi.com endpoints (llms.txt, AGENTS.md, agents.txt, .well-known/agent, .well-known/ai-plugin.json) all timed out at DNS resolution, indicating the domain is geo-blocked or otherwise inaccessible from this environment. No web search results surfaced any didi.com self-declaration files. Cannot confirm presence or absence.
Summary
Has agent interface: partial
Engage DiDi's open platform team via the partner inquiry form at didiglobal.com/contact/platform to request access to the ride-hailing OpenAPI or SDK; separately evaluate DiDi Pay (didipay.didiglobal.com) and DiDi Food (developer.didi-food.com) developer portals for their respective partner onboarding processes. No standardized agent protocol surface exists; any agent integration would need to be built on top of DiDi's proprietary partner APIs once credentials are obtained.
AgentContext
Verified discrepancies
Vendor claim: DiDi displays upfront fares and promotional discounts (e.g., 50% off first rides) that riders can review and accept before booking; the price shown at acceptance is represented as the price to be charged.
What actually happens: Multiple independently documented user accounts describe the final charged fare differing materially from the fare displayed at the time of booking acceptance. Patterns include: the fare increasing between acceptance and trip completion with no route change justification, promotional discounts shown at booking not being applied at payment, and drivers cancelling matched bookings and accepting other passengers — effectively displaying availability that is not honoured. These are not isolated anecdotes; the pattern appears consistently across the Australian market on Trustpilot and ProductReview.com.au.
Agent guidance: Do not rely on the fare displayed at booking acceptance as the amount that will be charged. Before completing any DiDi transaction on a user's behalf, record the displayed upfront fare and any promotional discount code; after trip completion, verify the actual charge matches. If a promotional discount is part of the booking rationale, treat it as unconfirmed until post-trip receipt is reviewed. If the final charge differs from the displayed fare, raise a dispute immediately via in-app or email before the session closes.
- Multiple Trustpilot reviewers of didiglobal.com describe a pattern where the price accepted at booking changes by the time the trip ends, with one reviewer calling it a 'bait and switch scheme' — a different price when you accept, when you board, and when you exit.
- ProductReview.com.au hosts multiple verified Australian DiDi user reviews describing promotional discounts (50% off) displayed at booking that are not applied at payment, and final fares materially higher than the upfront estimate shown.
- Apple App Store reviews for DiDi Rider (Australia) include detailed accounts of a 50% first-ride promotion displayed during booking that was not honoured at payment, with DiDi customer service failing to resolve despite documented proof.
Human handoff required for
Verify post-trip charge matches the upfront fare displayed at booking acceptance before closing the transaction — if the final charged amount differs from the fare shown at acceptance (including any promotional discount), escalate to a human to initiate a dispute before the session closes
- Multiple independently documented user accounts across Trustpilot and ProductReview.com.au describe the final charged fare differing materially from the fare displayed at booking acceptance, with no route-change justification, representing a consistent cross-platform pattern in the Australian market.
- Promotional discounts shown to users at the time of booking (e.g., 50% off first rides) are reported across multiple platforms as not being applied at payment, meaning the discount shown during booking does not reliably correspond to the discount applied at charge.
If a promotional discount code or offer was the rationale for selecting DiDi over an alternative, treat the discount as unconfirmed until the post-trip receipt is reviewed and the discounted amount is verified — do not finalise the transaction rationale until receipt confirmation is in hand
If a matched driver cancels the booking after the fare has been displayed and accepted but before the trip begins, do not treat this as a completed or billable transaction — escalate to a human to confirm no charge was applied before rebooking
Five categories were checked for discrepancies on didi.com. Discrepancy_pricing: searches found no evidence of hidden fees or checkout price gaps specific to the DiDi platform; results were dominated by the unrelated 2021 IPO securities settlement. Discrepancy_availability: a confirmed finding was identified — a consistent, multi-platform pattern of fares charged at trip end differing from fares displayed at booking acceptance, and promotional discounts shown at booking not applied at payment, documented across Trustpilot, ProductReview.com.au, and the Apple App Store primarily in the Australian market. Discrepancy_identity: searches returned general refund-difficulty complaints but no verified regulatory action or structural counterparty-liability mechanism that would meet the inclusion bar. Discrepancy_policy: DiDi's published cancellation and refund policies were located and reviewed; individual delayed-refund anecdotes were found but no systemic policy-versus-enforcement discrepancy was verified. Discrepancy_undisclosed_constraint: searches returned one anecdotal Trustpilot complaint about fares being estimates rather than finals, but no corroborating regulatory, investigative, or enforcement record was found to confirm a structural undisclosed constraint.