API structure
Sprinto Developer API is built on GraphQL technology and follows the standard call structures of GraphQL. If you've got experience with GraphQL APIs, you're in good shape — it'll make understanding the Sprinto Developer API a breeze. However, if GraphQL is new to you or it's been a while since you've worked with it, don't worry. You can use this learning resource to quickly brush up on the concepts.
The following guide will get you up to speed with the structure of the Sprinto Developer API.
Root Objects
Let's start with root objects, which are essentially the entry points for any GraphQL API call. The API calls start with either the root type as Query
or Mutation
, followed by the specific data field you want to query.
For instance:
query Query {
hello
}
In this example, the root type is Query
, indicating that the API call entry is for fetching data from the server. The query field is hello
, defining the type of specific data it is fetching.
Reading Data
GraphQL APIs can uniquely fetch specific data portions from various available fields on the server. Two fundamental tools, namely Query and Arguments, empower you to tailor your API call for your desired response.
Query
Let's explore the various queries our API supports by referring to our API schema. Use the below link based on your geographic location to access our API playground:
- United States: Sprinto API Playground
- Europe: Sprinto API Playground
- India: Sprinto API Playground
Prerequisite to access API schema: Set up Sprinto API Playground
In case you need help to set up the API Playground, we have got it covered for you.
All your Developer API query calls kick off with the root type Query
, followed by the specific query type detailing the data type you wish to retrieve from the server.
Illustrative Example:
query WorkflowChecksPaginated {
workflowChecksPaginated {
# Additional fields to be retrieved
}
}
Breaking down the above example query, this API call begins with the root type Query
, signalling its purpose as a data retrieval operation. The query field, workflowChecksPaginated
clarifies that we are fetching implemented compliance controls data.
GraphQL APIs have the superpower of fetching a specific subset of data from many available fields on the server. Query
and Arguments
are tools that help customise your API call to define the desired response.
Arguments
Arguments are pivotal in fine-tuning your GraphQL queries to extract specific information from the vast data landscape. Let's validate the use of arguments with a practical example:
query WorkflowChecksPaginated($first: Int, $after: String) {
workflowChecksPaginated(first: $first, after: $after) {
# Additional fields to be retrieved
}
}
In this illustrative example, we've introduced two additional fields: first
and after
. These fields are enclosed in parentheses and are placeholders for variables requiring input.
Understanding the Arguments:
first
: This argument demands an input in the form of an integer. Your input determines the number of nodes to retrieve from your Sprinto account.
after
: The argument requires an input in the form of a cursor
pointing to a specific node in the available graph. You can browse nodes that come after your mentioned cursor based on the argument in the query. Refer to Pagination to learn more about cursors
.
These arguments act as the guiding coordinates, allowing your query to navigate through the data and extract the precise information you seek.
Writing Data
While retrieving data is a crucial aspect of our API's functionality, there's another side to the coin – modifying data. This is where Mutation API calls come into play.
Mutation Exploration
To understand the mutation types our API supports, let's take a peek at our API schema. Use the below link based on your geographic location to access our API playground:
- United States: Sprinto API Playground
- Europe: Sprinto API Playground
- India: Sprinto API Playground
Prerequisite to access API schema: Set up Sprinto API Playground
In case you need help to set up the API Playground, we have got it covered for you.
All journeys into our Developer API's mutation realm begin with the root type Mutation. Following this, we pinpoint the mutation field to define the data type we wish to update.
Illustrative Example:
mutation Mutation($email: String!) {
markStaffAsInScope(email: $email) {
# Additional fields to be updated
}
}
Breaking it down, this example API call commences with the root type Mutation
, signalling our intent to modify data. The mutation field, markStaffAsInScope
specifies that the call is geared towards altering a staff member by marking them as In-scope.
Moreover, take note of the argument email
with the assigned type String!. The !
at the end of a type indicates that it is a required value. In this case, email
is necessary to identify the user, which should be marked as in-scope.
Updated 12 months ago