5 Best Grammar and Spell Checking APIs / SDKs

Try the Sapling API       Try the Sapling SDK

Grammar check APIs

Grammar and spell checkers have a long history as part of document processing applications. Today, simple systems exist in our browsers, email clients, and even our mobile keyboards. However, these systems tend not to go beyond basic spellchecking and autocorrect, and even then often have frustratingly low accuracy.

Today, popular systems such as Grammarly, Microsoft Editor, and Sapling offer functionality that goes beyond the built-in spellcheck of most applications. These systems offer browser and desktop integrations and make inline recommendations for ease of use.

Of course, it's impossible to integrate across all applications or provide a customized experience for each application. If a one-size-fits-all integration doesn't suit your application, you may consider using an application programming interface (API). These allow your application to interface with an existing grammar and spell checking system through a communication standard.

If you Google "grammar check API", many esoteric results will come up. This article tries to summarize the most useful APIs. For now, this covers English grammar check APIs, though we also include multilingual offerings in the future (Sapling supports many languages, which you can find here).

Example of grammar checking API flow with input query and output result.

Application programming interfaces

While APIs have a rich history, in this article we'll assume that an API exposes a set of web endpoints of a grammar application. Your application can make HTTP requests to these web endpoints in order to fetch the set of edits for a particular piece of text.

note

You may have heard of REST APIs. Sapling (and many other APIs) follow the REST style, but you don't need to know the details of REST to use these systems.

For example, suppose your application has a text input in which one of your users types the text: Helo world.

Your system uses a third-party API to retrieve edits. It sends the following JSON to a third-party POST endpoint:

{
  "query": "Helo world"
}

It then gets back the following JSON in response:

{
  "edits": [
    {
      "start": 0,
      "end": 4,
      "replacement": "Hello"
    },
    {
      "start": 5,
      "end": 10,
      "replacement": "world."
     }
  ]
}

These two edits fix the first misspelling and also add a missing period. The third-party service has detected all the edits you need. It's then up to your system to render the edits on your frontend to your user in whatever manner you see fit.

info

In case you're interested in autocomplete and similarity/semantic search, Sapling also offers APIs for those as well — please contact us.

Software development kits

Note that in addition to APIs, some systems also offer SDKs that can make it even easier to integrate their system. For example, Sapling offers an SDK that allows developers to integrate Sapling with 5 lines of JavaScript. We'll save more on SDKs for a separate article.

Building your own

Before we discuss providers, why use a third-party API instead of building your own? For example, there are great libraries out there such as Stanza for preprocessing of text, and also deep learning libraries such as TensorFlow and PyTorch that allow you to train your own system, and even higher-level libraries if you've decided on a specific model.

There are a few reasons why this is challenging.

1. Language is really complex. For every scenario you might come up with where you think a certain edit is appropriate, there are dozens if not hundreds of variations. If you're using a heuristic-based approach, you're likely not considering many of these variations. If you're using a machine learning-based approach, you'll need lots of data.
2. It'll take engineers some time to set up and maintain the system, and engineers are expensive. So too are servers if you'll be using a machine learning-based system that requires lots of compute. It's quite likely that using an API will not only be more time-efficient, but also cost-efficient.
3. You and your team have other things to focus on. If grammar correction and natural language processing are not a core competency, it's likely best to focus on your system's specialized offerings instead. Buying is almost always cheaper than building. As you likely rent cloud infrastructure from AWS or Azure, so too should you try and offload other services.

Providers

As of early 2022, here are some common grammar checkers/writing assistant tools that offer API access:

• Bing
• Ginger
• LanguageTool
• ProWritingAid
• Sapling

We'll use the following broad criteria when evaluating the different APIs:

• Overview: What type of API is offered? Does it do both grammar and spell checking, or exclusively spell checking?
• Strengths: What type of suggestions are given and what is the performance in terms of accuracy and recall?
• Latency: How long does it take for these systems to make suggestions for a typical query? This will of course depend on the document size, but parallelization should allow for scaling to large documents with latency then being the primary bottleneck.
• Other features: What other suggestions or information beyond the edits does the system provide? What are the language and deployment options?

Let's first give a brief introduction to the different systems.

Bing

The Bing Spell Check API helps correct spelling and adjust slang. It's especially helpful for brands and names as it also uses the Bing Search API.

Types of corrections include word breaks, slang, names, homonyms, and brands.

You can find out more about the Bing API on the Microsoft website: https://www.microsoft.com/en-us/bing/apis/bing-spell-check-api

Ginger

Ginger's grammar check API allows users to embed the Ginger system into their own application. While light on details, their information page mentions that it is used to check millions of documents a month. Given that the Ginger API provides a different interface to the Ginger platform, it's possible to get a sense of the performance by installing one of Ginger's other integrations, for example for the browser. Ginger is one of the grammar checking services that has been around longest — it was founded since 2010 — so you may have already tried its services and wish to try the API.

LanguageTool

LanguageTool is another of the most popular grammar checking programs that offers grammar, spelling, and style suggestions. LanguageTool has support for over 20 languages, though certain languages have a greater number of suggestions available. Its API offering can be hosted on-premises. It also offers the ability to specify the rules that should and should not be applied as well as set dictionaries.

ProWritingAid

ProWritingAid offers a grammar and spell check API for the system that also powers its own product. It offers SDKs in several languages, including C#, JavaScript, Python, PHP, and Java. Similar to Ginger, ProWritingAid is a popular solution that has been available since 2012, so you may be a user and wish to use the API as well. In addition to grammar and spell checking, ProWritingAid also offers thesaurus and text tagging endpoints.

Sapling

Sapling is the language model copilot for businesses. Its technology is based off of research in the Stanford AI lab.

The most recently developed of the solutions described here, Sapling is specifically geared towards business teams such as customer support teams or inside sales teams.

Sapling uses a learning-based approach to catch up to 60% more errors than other systems. Users can provision a test API key themselves right after signing up for an account.

You can find out more about the Sapling API here.

Comparison

We've included a table below summarizing some of the benefits and drawbacks of the different systems.

Provider	Overview	Strengths	Latency	Other Features
Bing	Available with Azure subscription. Only supports spell checking.	Highly scalable system, leverages Bing Search API, multilingual support.	<0.3 seconds	Market code customization in addition to language code.
Ginger	REST API, English dialects.	Detailed metadata for edits.	?	Synonym and vocabulary recommendations.
LanguageTool	REST API, multiple languages.	Support for many languages, self-hosting options.	<2 seconds	<2 seconds
ProWritingAid	REST API, detailed error categories.	REST API, detailed error categories.	?	Thesaurus, SDKs available, text tagging.
Sapling	Machine learning-powered system designed for the enterprise. Self-serve.	Learning-based system that catches complex errors, self-hosting, multiple languages.	~1 second	Error categories, self-hosting, and SDK available.

Comparison of API providers.

Which solution is best?

The best solution depends on your use case. Since there are many considerations here, we won't make a recommendation besides to try out each. But please consider the next section on evaluation.

Note on evaluation

Sometimes evaluation criteria are obvious — for example, to evaluate the latency of a system you would submit text of varying length and record the wall-clock time elapsed.

info

Constructing a sizable evaluation dataset with examples from real-world usage is the best way to judge the performance of different systems.

From talking to users, we've frequently seen poor practices when it comes to evaluating different systems for accuracy and recall. Oftentimes, users will start by entering intentional errors such as the following:

Helo howare u.

fdsafsdafdsa.

It seems natural that a spelling and grammar checking system should flag these errors.

This approach, however, favors strict approaches, such as those that use simple dictionaries and lookup tables — let's call these classical approaches — instead of approaches that learn based off of real-world data — we'll call these learning-based approaches.

Learning-based approaches are not trained on intentional errors, but actual errors seen in practice, and therefore can perform worse than classical approaches on blatant errors such as the ones in the example above. However, if you consider actual usage, learning-based approaches tend to capture many more errors and provide more useful suggestions.

We recommend constructing your own evaluation dataset of at least a few dozen sentences containing errors by collecting example sentences that you or others on your team have seen. These examples should also be representative of examples you expect in the future. This is the best way to ensure that you get a good estimate of the actual performance of the systems you're testing and also to avoid cherry picking of examples. You can read more about evaluation here.

Conclusion

We recommend that you try out all of the different APIs and see what best fits your use case. This is because the requirements for a medical application differ greatly from a legal application, which differ greatly from a customer service application.

Obviously, we're biased. Get started with Sapling's documentation: https://sapling.ai/docs

Or you can reach out to us here: https://sapling.ai/contact We're happy to talk through the customizations required for your particular use case. If you don't have time for a call, you can give Sapling a try using one of our our prebuilt integrations.

Other tools we didn't mention? Please let us know: team@sapling.ai