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).
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.
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:
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:
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.
Software development kits
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.
- 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.
- 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.
- 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.
As of early 2022, here are some common grammar checkers/writing assistant tools that offer API access:
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.
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'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 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.
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.
We've included a table below summarizing some of the benefits and drawbacks of the different systems.
|Available with Azure subscription. Only supports spell checking.
|Highly scalable system, leverages Bing Search API, multilingual support.
|Market code customization in addition to language code.
|REST API, English dialects.
|Detailed metadata for edits.
|Synonym and vocabulary recommendations.
|REST API, multiple languages.
|Support for many languages, self-hosting options.
|REST API, detailed error categories.
|REST API, detailed error categories.
|Thesaurus, SDKs available, text tagging.
|Machine learning-powered system designed for the enterprise. Self-serve.
|Learning-based system that catches complex errors, self-hosting, multiple languages.
|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.
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.
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.
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: email@example.com