Alexa.NET gives a C# developer a typed model of the whole Alexa API

A strongly typed model, not a JSON helper

Alexa.NET is a helper library for working with Alexa skill requests and responses in C#. The stated ambition is modest and specific: whether you are using the AWS Lambda service or hosting your own service on your server, the library aims to make working with the Alexa API more natural for a C# developer using a strongly typed object model.

That last clause is the whole design. The Alexa API is a JSON protocol with a large and fiddly surface, and a skill that has to build a response by hand ends up with string keys scattered through the code. A typed model turns those into classes, which means the compiler catches a misspelled property and the IDE can tell you what is available.

The library covers the request types that Alexa sends depending on the events you should respond to. The full list is AccountLinkSkillEventRequest, AudioPlayerRequest, DisplayElementSelectedRequest, IntentRequest, LaunchRequest, PermissionSkillEventRequest, PlaybackControllerRequest, SessionEndedRequest, SkillEventRequest and SystemExceptionRequest.

So the answer to what the library is for is: everything the Alexa service can send you, typed. And the answer to what it is not for is the JSON itself, which is where the second half of the story comes in.

The handler shape, and the serializer that fills it

The setup section is short because the model is fixed. Regardless of your architecture, your function for Alexa will be accepting a SkillRequest and returning a SkillResponse:

public SkillResponse FunctionHandler(SkillRequest input, ILambdaContext context)
{
    // your function logic goes here
    return new SkillResponse("OK");
}

The deserialization of the incoming request into a SkillRequest object will depend on your framework, which is the point where the library hands over to the AWS tooling.

That handoff is the Amazon.Lambda.Serialization.Json package, and the documentation says the default may be different depending on how you created your project. In your project file the references look like this:

<Project Sdk="Microsoft.NET.Sdk">
  <!-- ... -->
  <ItemGroup>
    <PackageReference Include="Alexa.NET" Version="1.15.0" />
    <PackageReference Include="Amazon.Lambda.Core" Version="1.2.0" />
    <PackageReference Include="Amazon.Lambda.Serialization.Json" Version="1.8.0" />
  </ItemGroup>
</Project>

And in any .cs file you add the assembly attribute that turns the Lambda function's JSON input into a .NET class:

// Assembly attribute to enable the Lambda function's JSON input to be converted into a .NET class.
[assembly: LambdaSerializer(typeof(Amazon.Lambda.Serialization.Json.JsonSerializer))]

One thing to notice: the example pins Alexa.NET at 1.15.0 while the newest release is 1.22.0, so the documentation is not tracking the latest package.

Responses, and the Ask versus Tell distinction

The responses section of the documentation is where a skill actually spends its time, and the model covers the main variations.

There is the Ask versus Tell distinction, which is the core of how an Alexa skill works: an Ask ends the turn with a question, a Tell ends it with a statement. Then there is an SSML response, an SSML response with a card, and an SSML response with a reprompt.

SSML is the speech markup, and the card is the visual output that appears on a screen device, and the reprompt is what Alexa says if the user does not answer. Having all three typed means a skill that shows a card and asks a question with a reprompt is a matter of filling in an object rather than assembling nested JSON.

There is also a section on session variables, which is how a skill holds state across a turn. And a section on responses without helpers, which is the escape hatch for the cases the typed model does not cover.

The last piece in the table of contents is progressive responses, which lets a skill send a partial response before the full one, for long operations. That is a separate mechanism from the ordinary response, and it is the kind of feature that has to be in the library rather than bolted on, because it changes the shape of the function handler rather than the shape of the response.

The extension ecosystem is most of the surface area

Alexa.NET serves as a base foundation for a set of further Alexa skill development extensions from Steven Pears, and the list is long enough to be worth reading in full, because it shows what the library does not cover on its own.

There is Management for the management API, InSkillPricing for in-skill purchasing, Messaging, Gadgets, Profile for the Customer and Person Profile API, and Settings for the Settings API.

There is APL support for the Alexa Presentation Language, Reminders, ProactiveEvents, CanFulfillIntentRequest, and Response Assertions, a test utility for asserting on responses.

There is SkillFlow support, marked experimental, and it comes in four parts: an object model, an interpreter, a text generator and a code generation tool. Then Timers, WebApiGames for the Web API for Games, ShoppingActions for the Shopping Kit, and two marked Beta: Conversations for the Conversations API and PinConfirmation.

Reading that list tells you something about how the Alexa skill ecosystem has fragmented. The core library is the request and response model, and every newer Alexa feature tends to arrive as a separate package, sometimes with a status label attached.

An old release tag and a recently touched branch

The version history is the thing to weigh before you adopt this.

The tagged releases are 1.22.0 from 2023-03-14, 1.21.0 from 2022-10-12 and 1.20.0 from 2022-01-29. The last push was on 2026-06-11, and the project is not archived. The repository also has an AGENTS.md, a .devcontainer directory, an all-contributors configuration and a contributors badge counting sixteen people, so there has been a broad group of contributors over the life of the project.

So the branch is being worked on while the published package has not been tagged since March 2023. For a library that models a third party API, that gap is partly explainable: the Alexa API moves, and a maintainer may prefer to fix forward on the branch than to publish a version that promises compatibility it cannot verify. It also means the version you get from NuGet is not the code in the repository.

The build and test setup is ordinary and modern enough. There is a Dockerfile based on the .NET Core SDK 7.0 image that also fetches the Visual Studio debugger, an Alexa.NET.sln solution with a separate Alexa.NET.Tests project, a testEnvironments.json, and a .NET Core build and deploy workflow badge on the master branch.

The case for a typed model over raw JSON

It is worth being explicit about why the typed layer is worth a dependency, because the objection is obvious.

The alternative is to work with the raw JSON that Lambda hands you, which is entirely possible, and to build responses as anonymous objects or dictionaries. In exchange for that you get no dependency, no version skew with the model, and no compile error when you typo a property name.

What you give up is discoverability and correctness. The Alexa response schema has nested objects with optional fields, a session attribute block, a card object with its own type union, and reprompt behaviour that depends on whether the turn is an Ask or a Tell. Learning that from the raw payload is slower than learning it from the type definitions, and the type definitions are checked by the compiler.

The other argument is the extension ecosystem. Those packages all build on the same model, so the object you get from a request in the core library is the object the APL package and the Timers package expect. Adopting the core library is effectively opting into that family, and the version numbers move together.

So the trade is a dependency and a version policy in exchange for a typed surface and a set of packages that would otherwise each need their own model. For a C# team already shipping a Lambda skill, that is usually a good trade.

Editorial conclusion

Adopt Alexa.NET if you are building an Alexa skill in C# and want the request and response shapes typed rather than assembled as dictionaries by hand. Do not adopt it if you have just started a skill in another language, since the whole value is the strongly typed C# surface, and note that the newest tagged release is 1.22.0 from 2023-03-14 while the last push was on 2026-06-11. Before you start, check two things: which request types your skill actually needs, since the library models ten of them and most skills use one or two, and whether the newer Alexa features you want are in the core library or in one of the extension packages by Steven Pears, since several of them are marked experimental or beta.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. Releases
5. timheuer/alexa-skills-dotnet on GitHub