Most of our customers have variable and various other third party applications and services with which
they want to push and pull data. Many of these other applications have APIs that are open and can be
used to accomplish this. In this way, really anything can connect with SimpliGov.
An Application Programming Interface (API) is basically a just a way that organizations say “Hey! If you
want to get to information that we have with a program that you’re writing, you can get to it through
here.” It is a way that two applications can talk directly to each other. Each time one system talks to
another, it is called a request. Even sending data to another system is still a request. There are lots of
services out there for creating and testing API calls. When we build workflows in SimpliGov that include
API calls, we usually use cURL, Postman, and RequestB.in to help set it up.
There are a number of different locations within the Webform and Workflow Builders in which designers
can set up API calls to other web services. Users can configure the API to make a variety of types of
requests, including GET, POST, and PUT requests. The request headers can also be edited to account for
variable content-types, or other headers that the user may want to include. Answers from the form or
document content can be included in the request body, as well as the headers, so they can be variable
and be dependent upon the answers in the form.
The SimpliGov API configuration allows for authentication, including Basic Authorization and OAuth 2. It
also includes the ability to preserve the authentication. This allows for two scenarios:
• Users can be presented with an OAuth window while they are filling out the form, which would
make sense if they should be using their own account for the integration to work.
• The OAuth window can also be filled out during configuration, and the system can continue to
refresh the token to allow an invisible integration with that third party endpoint. This method
would be more appropriate for use with system accounts, essentially one account that should
be used all the time.
SimpliGov can validate the responses of the API to make sure that the request is correct. If the request is
incorrect according to the rules that have been set up, the system can prevent the user from submitting
the form, or it can yield an error on a specific field. The rules that are set up can reference a certain
piece of the response, like if the response contains an error field, or the HTTP status code, like 404.
There are two main ways to use the API, and two main reasons for doing so:
• SimpliGov allows for API calls to be made at the stage level, which means that the API calls can
go out and get information based on a form answer as someone is editing it. This can be useful
to fill information into the form while a user is editing the form.
• The API calls can also be made at the relationship level, which is useful for POSTing data to a
database after the form has been filled out, or integrating with a payment processor. The
responses from the system can be mapped into the form at this point as well. With either of
these methods, both at the stage or relationship level, the responses can be used to drive
workflow logic.
External Data Sources
External data sources are very similar to the External API module in terms of configuration concepts, but
are built for a different use case. External Data Source and External Grid Data Source allow users to