GraphQL API Examples

Each API call has the following content:

• HTTP Request URL - Identifies the Glartek GraphQL Endpoint to where the request is sent;
  
• Content-Type header - Identifies the content of the body of the request (JSON);
  
• Authorization header - Includes the Authorization token that was previously generated;
  
• Content - Query to be performed.
  

Below is an example of a full query with authorization token to fetch the list of issues (ordered alphabetically):

Below is an example of a request to fetch the list of actions. The content to fetch can be defined in the query (in this case: _id, name, site's name and assignedAccounts' name).

Response:

Below is an example of a request to fetch the list of accounts and some of its content. The content to fetch can be defined in the query (in this case: _id, name and email).

Response:

Below is an example fetching Sites and Elements with some filters. We want Sites that contain "Glartek" in their name and Elements that are called "Cadeira". In this case, we are using inline fragments (... on LeanSite), which allows to fetch objects that can be of different types. In this case, the object can be of type LeanSite or LeanElement, which have different fields, so using the inline fragment, we can select which fields we want specifically from each type.

Response:

Below is an example of a query to fetch all the responses of a specific type of work order. You can search for the ID in the Glartek Web App or directly on the API.

Response:

Example on how to create an Action. Here we are just passing name and site as variables, because these are required in this mutation. However, we can change other fields such as description, dueDate, etc... The same applies to the response, we asked for ID, name, site's id and site's name, but we can request others like createdAt, dueDate, etc...

Response example:

Example of an update of a site attribute (in this case, we are changing the name of the Site).

If the request is valid, it will return a response like this:

For this mutation, we are changing an Input from a task currently running in a work order. In this case, we are changing an InputNumber, but we can also change a text, a selection box, a file, etc., depending on the task input.

Response:

The creation of a PDF report is slightly different than the other requests, because the report is not generated instantly, it is an asynchronous process. To create a report, we must pass the contentId, which is the id of the issue we are generating the PDF report from, and the contentType, which at the moment can only be of type "issue". Then, we can choose if the PDF is simple or detailed, through the pdfType field.

With this in mind, let's create the report:

Response: 

We can observe that the report is yet to be generated, because in the response, the status says that it is queued. You can use _id of the report you just created and execute the following query, every minute or so, to get an update of the status:

The status indicates that the PDF report is finished, and the field ULR will contain the reference to the report file:

Note that the URL to the PDF file expires after 5 minutes. It should be downloaded as soon as it is made available.

When there is a block of code that will be repeated, you can use fragments. Fragments are reusable units that let you construct sets of fields and reuse them in different queries or mutations. For example:

For more information please contact us.