Completed

Real Estate AI Chatbot with ASP.NET Core

A production-oriented AI chatbot built with ASP.NET Core on .NET 10: Claude answers real estate questions on buying, selling, mortgages, investing and renting, streamed token by token over SignalR, with JWT authentication, per-user conversation history in SQL Server through EF Core, and clean architecture behind a swappable AI provider.

.NET 10ASP.NET CoreSignalRClaude APIAnthropic .NET SDKEF CoreSQL ServerJWTRazor PagesxUnit

Source on GitHub ↗

The problem

A chatbot demo is one HTTP call to a model; a chatbot people can actually use is not. Answers have to stream instead of timing out, every user's conversations have to be stored and kept private, a provider outage or refusal must not lose what the user typed or leave a half-answer, and the assistant has to stay inside its domain — here real estate, where it must show its working, admit it has no live listings, and stop short of legal, tax or financial advice.

Engineering focus

Streaming LLM responses over SignalR
Claude API from C# with the Anthropic SDK
Clean architecture and a swappable AI provider
JWT authentication and per-user data isolation
Conversation history with EF Core and SQL Server
Rate limiting, Problem Details and security headers
System-prompt guardrails for a domain assistant
Unit and integration tests with a fake AI provider

In use

The chat answering 'I'm a first-time buyer earning $90,000 a year with $40,000 saved. What price range should I target?' with a heading, a $250,000–$275,000 estimate and a 28% / 36% rule table still being written — An answer mid-stream. Each token arrives as a SignalR ReceiveDelta event and is rendered as Markdown as it lands — here the 36% rule row of the table is still being written.

A Python monthly_mortgage_payment function in a highlighted code block with a python label and a Copy button, written in reply to a mortgage calculator request — Fenced code comes back with a language tag, so the client highlights it and adds a copy button. The model's Markdown is sanitised with DOMPurify before it reaches the page.

A follow-up answer comparing 15-year and 30-year mortgages on $350,000 at 6.5%: a payment table, code reusing the earlier Python function, its output, and a Things to Weigh list — A follow-up in the same conversation. The last 40 messages are sent as context, so the comparison reuses the function written in the previous answer. Under each reply: its time and the model that served it.

A listing description for a renovated 3-bed townhouse across from a park, with tips that include keeping the copy buyer-neutral for fair housing, and four conversations in the sidebar — A listing description, with the fair-housing guardrail from the system prompt showing up in the tips. Each conversation is titled from its first message and stored per user in SQL Server.

The chat in light theme: a Monthly Mortgage Payment Calculator answer with the amortization formula, a symbol table and the start of a Python function — Light theme. Code blocks keep a dark background in both themes.

An empty new conversation: 'How can I help today?', a message box with 'Enter to send, Shift+Enter for a new line', and a green connection dot in the header — A new conversation. The green dot is the SignalR connection; while it is down the client reconnects automatically and sends over POST /api/chat instead.

The Create account form: display name, email and password fields with the hint 'At least 8 characters, including a letter and a digit' — Registration returns a JWT. Passwords are hashed with ASP.NET Core Identity's PBKDF2 hasher, and the auth endpoints are rate-limited per IP.

The listing description answer on a phone-width screen, with a menu button and the conversation title in the header — On a phone the sidebar collapses behind a menu button.

The mobile conversation drawer open over the chat: New conversation, four saved conversations with delete buttons, and Sign out — The conversation drawer on mobile.

How it works

Streaming over SignalR: The client invokes ChatHub.SendMessage. The hub pushes UserMessageSaved once the message is stored, then a ReceiveDelta per chunk, and the call completes with the final response. The API always streams from Claude, so the plain POST /api/chat endpoint shares the same code path.
Save first, then call the model: The user's message is written to SQL Server before the AI call, so an outage never loses it. If the client disconnects mid-answer, generation is cancelled and the partial reply is saved; same-role turns left behind by a failure are merged when the next request is built.
Swappable AI provider: Application code depends only on IAiChatService. AnthropicChatService implements it with the official Anthropic SDK and reports the model, token counts and stop reason; switching provider is one class and one DI line, and the tests use a fake.
Refusal handling: Requests opt into the API's server-side fallback, so a turn the model declines is retried on a fallback model. If it still ends with stop_reason refusal, a short notice is returned instead of a partial answer.
Ownership by query: Repositories only load conversations where UserId matches the signed-in user, so another user's conversation looks exactly like a 404 and IDs cannot be probed.
Limits and errors: One per-user chat rate limit is shared by REST and SignalR, with separate global and per-IP auth limits. Request and hub message sizes are capped, and every error is an RFC 9457 Problem Details response with a trace id. Logs carry IDs and token counts, never message content.

Architecture

Real Estate AI Chatbot with ASP.NET Core

.NET 10ASP.NET CoreSignalRClaude APIAnthropic .NET SDKEF CoreSQL ServerJWTRazor PagesxUnit

Source on GitHub ↗

The problem

Engineering focus

Streaming LLM responses over SignalR

Claude API from C# with the Anthropic SDK

Clean architecture and a swappable AI provider

JWT authentication and per-user data isolation

Conversation history with EF Core and SQL Server

Rate limiting, Problem Details and security headers

System-prompt guardrails for a domain assistant

Unit and integration tests with a fake AI provider

In use

How it works

Streaming over SignalR

The client invokes ChatHub.SendMessage. The hub pushes UserMessageSaved once the message is stored, then a ReceiveDelta per chunk, and the call completes with the final response. The API always streams from Claude, so the plain POST /api/chat endpoint shares the same code path.

Save first, then call the model

The user's message is written to SQL Server before the AI call, so an outage never loses it. If the client disconnects mid-answer, generation is cancelled and the partial reply is saved; same-role turns left behind by a failure are merged when the next request is built.

Swappable AI provider

Application code depends only on IAiChatService. AnthropicChatService implements it with the official Anthropic SDK and reports the model, token counts and stop reason; switching provider is one class and one DI line, and the tests use a fake.

Refusal handling

Requests opt into the API's server-side fallback, so a turn the model declines is retried on a fallback model. If it still ends with stop_reason refusal, a short notice is returned instead of a partial answer.

Ownership by query

Repositories only load conversations where UserId matches the signed-in user, so another user's conversation looks exactly like a 404 and IDs cannot be probed.

Limits and errors

One per-user chat rate limit is shared by REST and SignalR, with separate global and per-IP auth limits. Request and hub message sizes are capped, and every error is an RFC 9457 Problem Details response with a trace id. Logs carry IDs and token counts, never message content.