i build .net clients for ai apis, so i keep a running map of which providers actually support .net developers and which leave them hand-rolling http. the short version: “no .net sdk” is no longer the main problem. the main problem now is autogenerated .net sdks that technically exist but nobody enjoys using.

here’s the field, in three buckets.

bucket 1: official, hand-maintained (the good ones)

these vendors treat .net as a first-class citizen. if you’re on one of these, you’re fine.

• OpenAI — official .net sdk, microsoft-backed. first-class.
• Anthropic — official c# sdk (anthropic on nuget). recent, real.
• Azure OpenAI — microsoft’s own, obviously excellent.
• Deepgram — official deepgram-dotnet-sdk, targets net6/7/8. voice ai done right for .net.
• Qdrant — official .net client for the vector db.
• Pinecone — official .net sdk, microsoft-announced, wired into semantic kernel.

takeaway: the biggest names have closed the gap. good for developers, not a market for me.

bucket 2: autogenerated or experimental (the real opportunity)

these have a .net client, but it’s machine-generated from an openapi spec (often by the community tryagi project) or, increasingly, ai-generated by the vendor themselves. they compile. they’re also not idiomatic, thinly tested, and rough where the api gets interesting (agents, streaming, wire-format quirks). enterprise .net teams feel the difference immediately.

• Cohere — .net via tryagi autogen; no hand-crafted company client.
• Tavily — tryagi autogen.
• Groq — tryagi autogen (and openai-compatible, so most people just use the openai sdk).
• Mistral — community + tryagi for chat; nothing official, and nothing covered the agents api until
  i built Mistral.Agents.Net.
• Apify — an official .net client that the vendor openly labels “experimental, ai-generated and
  ai-maintained.” decent, but the label says it all.
• ElevenLabs — official sdks for python, ts, kotlin, swift; .net is community only, and the realtime
  agents layer wasn’t covered until ElevenAgents.Net.

takeaway: this is the new gap. the sdk exists, but it’s autogen. “you have a .net sdk” and “your .net sdk is good” are different sentences, and enterprise buyers notice.

bucket 3: missing or community-only

no official .net at all — just a community package of varying quality, or nothing.

• Together AI — no official .net.
• Cartesia — no .net.
• Firecrawl — community / autogen only.
• Plaid — node/python/ruby/java/go official; no official .net (community Going.Plaid). and this is
  fintech, where the .net enterprise audience is huge.
• Polygon.io — market data; no official .net.
• Vapi / Retell / Hume / Browserbase — mostly missing.
• AssemblyAI — special case: shipped an official c# sdk, then discontinued it in april 2025. .net
  users who adopted it are now on an unmaintained client. the clearest signal of all that .net gets
  treated as an afterthought.

takeaway: still real gaps, especially in fintech and the newer voice/agent startups whose enterprise customers are exactly the .net crowd — and vendors who shipped a .net sdk and then walked away.

the thing nobody’s saying

the industry quietly decided that “generate a .net sdk from the openapi spec” equals “support .net.” it doesn’t. autogenerated clients handle the boring 80% and fall apart on the 20% that matters — the agentic surfaces, the streaming, the wire-format quirks you only find by running against the live api. (mistral’s agents api returns function-call arguments as a json string, not an object. no generator catches that. you find it on the first real call, in production.)

if you’re a vendor with a python-first api and an autogenerated .net client, your enterprise .net users are the ones paying for that gap — in time, in bugs, in a worse first impression than your python users get. that’s fixable.

i hand-craft production .net clients and mcp servers for ai apis — idiomatic, live-verified, documented. if your .net story is a bucket-2 or bucket-3 entry, let’s talk.