Sprinto Developer API

API structure

Suggest Edits

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:

ℹ️

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, workflowChecksPaginatedclarifies 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:

ℹ️

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, markStaffAsInScopespecifies 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 10 months ago