ShopifySharp turns Shopify's GraphQL API into a .NET client

The library takes over the parts everyone rewrites

ShopifySharp is described as a .NET library that helps developers build custom Shopify apps using C#, .NET and GraphQL, and it handles the tricky parts of authentication and validation so you can get up and running quickly.

That sentence is a fair description of the whole category. The Shopify Admin API is capable, but a working integration against it involves a non trivial amount of setup that every project otherwise repeats: a private app or custom app with a shared secret, an access token exchange, HMAC validation of incoming webhook payloads so you can tell a genuine callback from a forged one, a redirect flow for OAuth when the app is installed, and a GraphQL endpoint whose schema changes with every quarterly API version.

The audience for the library is therefore the .NET developer building a real integration, not someone making one API call. The README is explicit that the library is for building custom Shopify apps, and it points at a migration guide for developers already using ShopifySharp who need to move from Shopify's REST API to the GraphQL API, using the GraphService.

The commercial side of the project is worth noting up front, because it shapes what the repository contains. Alongside the library there is The Shopify Development Handbook, a premium educational course that distils the experience of building Shopify applications and integrations. The README argues that building a Shopify app is hard work and lists the questions a developer will be asking themselves, from what GraphQL is and how to use it with .NET through to billing, embedded apps, redirect URLs, proxy pages, webhooks, script tags and testing. It notes that this kind of guidance is hard to find for C# and ASP.NET developers in particular.

The repository itself is the library and the documentation site. The course is a separate product, and the README is upfront that the full documentation for ShopifySharp and its utility packages lives on shopifysharp.net, with the author noting that all of it was written by a human rather than a language model.

GraphQL is the main path, and the entities are generated

The GraphQL side of the project is where most of the engineering is visible, and the repository layout shows it.

There is a GraphService, which is the component that sends queries and mutations to Shopify, and there is a dedicated documentation page about migrating to GraphQL with it. Alongside that sits ShopifySharp.GraphQL.Parser, a separate project for parsing GraphQL, with its own CLI project, ShopifySharp.GraphQL.Parser.CLI, and its own test projects, ShopifySharp.GraphQL.Parser.Tests and ShopifySharp.GraphQL.Parser.Tests.Stubs.

The generated code is the interesting part. The repository contains a graphql-schemas/ directory, a graphql.schema.json file and a graphql.config.yml, and the justfile refers to a path for the generated GraphQL entities folder, ShopifySharp/Entities/GraphQL/Generated. So the library's GraphQL entity types are not written by hand, they are produced from the schema, and there is a dedicated build step that regenerates them and a clean task that removes the generated directory with git clean.

That approach has a direct consequence for a consumer. When Shopify publishes a new API version with new fields and new types, the library can absorb that change by regenerating from the schema, and your code gets new strongly typed properties. The cost is that the surface of the library changes when the schema does, which is why the version support table matters so much.

The justfile also shows that the project is built with just, a command runner, and that the CLI project is only rebuilt if its Release output directory is missing, which is a small touch that keeps repeated local builds fast.

Two NuGet packages, and the install command is one line

ShopifySharp is available on NuGet, and the README gives the dotnet command line installation for the packages it publishes.

There are two of them. The main package is ShopifySharp, installed with `dotnet add package shopifysharp`, and the second is ShopifySharp.Extensions.DependencyInjection, installed with `dotnet add package shopifysharp.extensions.dependencyinjection`. The library also has a ShopifySharp.slnx solution file and a Directory.Packages.props file, which is the central package management file that pins versions for the whole repository.

The dependency injection package is the one to think about, because it is a different kind of integration. In a .NET application, the service objects that ShopifySharp needs, the ones that hold a shop domain and a token and know how to call the API, are registered in the container so that the rest of the application can take them as constructor dependencies. The extension package exists so that you do not have to write that registration by hand and so that the registrations are consistent with what the library expects.

That is a small package, but it is the difference between ShopifySharp being usable in a modern ASP.NET application and being something you instantiate manually. The README links separate documentation pages for each of the two packages.

One structural note from the repository listing. The main library project lives in a directory named ShopifySharp, and there is a parallel ShopifySharp.Extensions.DependencyInjection project and a ShopifySharp.Extensions.DependencyInjection.Tests project. The tests live beside the code they cover rather than in one central test folder, which is the convention for a solution with several shipping packages.

The version table is the part integrators have to read

Shopify versions its API on a date based schedule, meaning new features are locked behind newer API versions while older versions lose support and are eventually shut off. ShopifySharp versions itself with SemVer. Those two schemes do not line up, so the README publishes a table that maps one to the other, and it says outright that the table should be consulted to determine which version of ShopifySharp supports which version of the Shopify API.

| 6.26.0 - 6.28.0       | 2026-01             |
| 6.25.3 - 6.25.4       | 2025-07             |
| 6.20.0 - 6.25.2       | 2024-10             |

The table is long, because the library has been around for a long time, and it is a genuine maintenance instrument rather than decoration. Each row is a range of ShopifySharp versions paired with the Shopify API version those versions were built against. The most recent releases are 6.30.0 on 2026-09-28, 6.29.0 on 2026-09-10 and 6.28.0 on 2026-03-04, and the last push to the repository was on 2026-09-28, so the current line tracks the 2026-07 API version.

The bottom of the table is the part with teeth in it. Versions 4.x and below are marked as having no Shopify API version and being unsupported. So a project that adopted ShopifySharp early has to move, and the table is how you work out how far.

For a team, the practical consequence is that upgrading ShopifySharp is not a routine dependency bump. It is a step that has to be paired with a decision about which Shopify API version you are targeting, and the two have to be changed in the same release, because ShopifySharp's models and query building are generated against a specific schema.

The justfile shows a multi-targeted, multi-project build

The justfile in the repository root is a good map of the build, and it covers a lot of ground.

The library is built for two target frameworks, net10.0 and net472, the current .NET and the .NET Framework. That pairing is what a .NET library that is expected to be consumed by both modern ASP.NET applications and older line of business systems looks like, and it is also why the README starts to describe the oldest supported .NET Framework version at the point where the excerpt ends.

The packing step is straightforward and shows the release mechanics:

    dotnet pack \
        -c "{{ config }}" \
        --version-suffix "{{ revision }}" \
        -o "{{ outputDir }}" \
        --verbosity "{{ verbosity }}" \
        "{{ project }}"

The build runs twice, once with a version suffix for the prerelease configuration and once without it for the release configuration, which is how a single command produces both a prerelease and a stable package.

Two other variables in the justfile are worth noticing. The path to the generated GraphQL entities folder is a named variable, and there is a separate task that removes it with git clean, with a comment explaining that git checkout does not work in jj changesets so the recipe falls back to jj restore when jj is present. That is a small sign of a project that uses version control workflows beyond plain git, and it is the kind of detail that tells you the maintainer is comfortable with more than one tool.

The documentation site is built by the same file, from a docs directory that the justfile points at, and the project has a global.json for the SDK version and a graphql.config.yml for the schema tooling.

Unit, integration, parser and stub tests, with secrets kept out of the repo

The test layout in the repository tells you what the project considers worth verifying.

There is ShopifySharp.Tests for the main library, ShopifySharp.Tests.Integration for tests that talk to Shopify, ShopifySharp.GraphQL.Parser.Tests for the parser, and ShopifySharp.GraphQL.Parser.Tests.Stubs for the fixtures those parser tests run against. The justfile names the specific test classes that cover the GraphQL query builders, among them the product query tests, the query builder tests, the query builder mutation tests, the HTTP content serializer tests, the union type converter tests and the union cases builder base tests. That is a specific list, which suggests the query builder layer is the part of the library with the most surface area and therefore the most attention.

The integration test project exists precisely because a client library for a remote API cannot be verified by unit tests alone, and the repository has an encrypted environment file for it. The justfile points at env.encrypted.json, described as the sops encrypted environment file used for unit tests in CI and CD, and the repository root has a .sops.yaml configuration and a global.json. The credentials for the integration tests are therefore encrypted at rest and decrypted in the pipeline, rather than living in the repository or in a plain environment file.

For a reader, the notable point is that the GraphQL query builder, which is the part you will use most, is the part with a named test suite, and that the integration tests exist at all. What the README does not document is how to obtain the Shopify credentials the integration tests need, so that part of the picture has to be worked out from the pipeline configuration.

MIT, an active release line, and a documentation site written by hand

The licence is MIT, with the LICENSE file at the repository root, and there is an attributions.md file beside it for third party credits.

The maintenance picture is the healthiest of any library in this set. Releases are frequent, the newest one was published on the same day as the last push, and the version line is in the 6.x range with a clear map to the Shopify API versions it serves. The NuGet badge in the README tracks the published version, and the build status badge points at a GitHub Actions workflow called build-and-test, so the build and the tests are run on every change.

The documentation is hosted at shopifysharp.net, and the README says that all of it was written by a human, with a joke about a bygone ritual of ink oblation and a rule that no language model is permitted to worship at the altar. Whether or not you find that amusing, it is a statement of policy about how the documentation is produced, and it is unusual enough to be worth noting for anyone who plans to rely on the docs as a reference.

What the project does not do is document the application level concerns of a Shopify app in the repository itself. Billing through Shopify, embedded apps, redirect URL handling, proxy pages, webhook handling, script tags and app testing are all listed in the README as things a developer will have to work out, and the answer offered is the paid handbook rather than the library documentation. That is a deliberate line. The library covers the API surface, and the course covers the rest of building an app, which means an integrator looking for embedded app guidance in the open source project will not find it.

Editorial conclusion

Adopt ShopifySharp if you are building a Shopify app or integration in C# and want the authentication flow, the GraphQL query building and the version mapping worked out for you, and if you are prepared to track Shopify's API version cycle. Do not adopt it if you are working in another language, since the value is in the .NET specific surface, and do not expect it to cover the parts of a Shopify app that are not API calls, because billing, embedded apps, webhooks and app proxies are documented in a separate paid handbook rather than in the library. Before you start, look up your Shopify API version in the support table to find the ShopifySharp version that covers it, and read the GraphQL migration page if you are moving an existing integration off the REST API.

Frequently asked questions

Official sources

1. License: MIT
2. nozzlegear/ShopifySharp on GitHub
3. Project website
4. README
5. Releases