Table of Contents |
---|
See Saved Queries on how to create a saved query. The URL can be found on the Execute Query screen.
GET
https://<Cinchy Web URL>/API/MyDomain/MyQuery
To access any Cinchy Saved Query API, pass the access token received from the Bearer Token Request in the Authorization header, prefixed by "Bearer".
%40 is the URL encoded version of @, if you are passing them in as parameters you will need to include the %40 in front of your parameter name.
https://<Cinchy Web URL>/BasicAuthAPI/MyDomain/MyQuery
The following instructions detail how to allow anonymous access to your saved query API endpoint.
Navigate to the table your query will be referencing. In this example, it is the Accessibility Assessments table (Image 1).
Navigate to Data Controls > Entitlements.
On a new row, add in the Anonymous user and ensure that either "View All Comuns" (to expose all the data) or "View Selected Columns" (to select individual columns) is checked off (Image 1).
Clicking on inline images in Gitbook will open a larger version.
4. Design your query (Image 2). For more information on creating new saved queries, click here.
5. Once you have written your query, navigate to Design Query > Info, on the left navigation bar.
6. Change your API Result Format to JSON (Image 3).
7. Navigate to Design Controls from the left navigation bar.
8. To ensure that anonymous users have the correct permission needed to execute the query that generates the API response, add the "Anonymous" user to the users permission group uiunder "Who can execute this query?" (Image 4).
9. Navigate to "Execute Query" from the left navigation bar.
10. Copy your REST API endpoint URL (Image 5).
11. To confirm that anonymous access has been successfully set up, paste the URL into an incognito/private browser (Image 6).
401
errors likely mean you have not added the Anonymous
user to the list of users (not "Groups") that can execute the query.
400
errors likely mean that you have not added the Anonymous
user to the list of users that (not "Groups") that can view column data from the tables that your query uses.
Name | Type | Description |
---|---|---|
Name | Type | Description |
---|---|---|
WrapSingleRecordInArray
boolean
Default is true. Add this parameter and set to false if you want single record results returned as an object instead of within an array.
@param
string
If you have parameters in your query, you pass them indirectly as query parameters.
CompressJSON
boolean
Default is true. Add this parameter and set to false if you want the JSON that is returned to be expanded rather than having the schema being returned separately.
Authorization
string
Bearer <token goes here>
You can query or manipulate any data on the Cinchy Platform through CQL (see Cinchy Query Language for more details on syntax). You can save that as a Saved Query which allows it to be accessed via an API endpoint.
You will need to first a Cinchy bearer token (see Authentication), and then you can either access a pre-defined Saved Query via the Saved Query endpoints, or perform freeform querying via the ExecuteCQL endpoint.
Note that regardless of how you query or manipulate data on the platform, it is associated back to an account.
This page describes the Cinchy Webhook ingestion, including a video walkthrough and step-by-step guide
Compatibility: Webhook ingestion was introduced in Cinchy platform v4.21. Note that previous Cinchy versions will not include a Webhooks system table, and will not support this feature.
Context: A webhook uses a trigger event to initiate a data transfer that can then be ingested by another application. Many applications support webhooks to provide data updates in real time with minimal configuration required. Cinchy users can subscribe to and ingest webhooks via configuring a unique API endpoint. When the external application addresses this endpoint, a pre-identified saved query can be run, under an authorized user account, to ingest the data and insert or update it into Cinchy.
The following video walks you through a specific configuration, with a general step-by-step guide below:
Identify the table in Cinchy that you want the information to be pushed to. (Image 1)
Tip: Click here for instructions on creating a table within Cinchy.
2. Create your query in Cinchy. This query should take data from the webhook event, and push it into the Cinchy table that you identified in Step 1. (Image 2)
Your query will be running under a specific user account that you will assign in the next step. Ensure that whichever user you choose for this purpose has the correct permissions to execute the query, and to insert / update data in the target table.
Tip: Click here for instructions on creating a query within Cinchy.
Note: You will need administrator access to your Cinchy platform to perform Step 3.
3. Navigate to the webhooks table in Cinchy, and populate the following columns (Image 3):
Key: This can be any string (we recommend that you treat this like a password and make it random and unguessable).
Run As: Insert the user who will be running this query here. This should be the same user to whom you gave permissions in Step 2a.
Saved Query: Select the saved query that you created in Step 2.
Forward Payload as Parameter: This column will depend on the manner in which you would like to ingest the webhook payload.
If you are configuring individual parameters in the webhook payload (for example: @name, @url, etc.), you may leave this column blank.
If you are not configuring individual parameters, as an alternative you can ingest the entire payload under one parameter and specify it in this field. In the below image, we have defined it as “JSON”. This means that the full payload (which happens to be a JSON file in this case) will be parameterized as @JSON and then inserted into a table column named JSON.
4. In your source application, navigate to the webhook settings and configure the following:
URL: This will be your Base URL + /API/callback?key= + the key value that you assigned in Step 3a.
Example: {baseURL}/API/callback?key=rGh5tfgHK8989J5
You can execute CQL directly without creating a Saved Query using the following endpoint.
https://<Cinchy Web URL>/API/ExecuteCQL
Name | Data Type | Description |
---|---|---|
200 (OK)
To pass in parameters in your executeCQL, you will need to pass in sets of parameters in the following format. So if you have one parameter then you would pass in 3 query parameters beginning with Parameters[0].
, and if you have a second parameter you would include an additional 3 query parameters beginning with Parameters[1].
.
The APIs in Cinchy use bearer token based authentication. This token is issued by the Cinchy SSO using the OAuth 2.0 Resource Owner Password Flow and can be retrieved for any Cinchy User Account or SSO Account. API calls made using a bearer token will run under the privileges of the authenticated user, and are driven by the configured data level access controls. You must include the token in each request in the Authorization header.
APIs that are dynamically generated through a Saved Query in Cinchy also allow for basic authentication. In this case, the url to the saved query is different, it will be:
https://<Cinchy Web URL>/BasicAuthAPI/MyDomain/MyQuery
The Resource Owner Password Flow uses a combination of a client id, client secret, username, and password to authenticate both the calling application as well as the user. To get started with, you must register a client in Cinchy. You should use a different client id for each calling application to distinguish activity from each source.
Clients are managed in the Integrated Clients
table within the Cinchy
domain. To register a client, create a new record in this table. In a fresh install, only members of the Cinchy Administrators
group will have access to perform this function.
Below is a description of the value that should be used for each column in the Integrated Clients
table.
https://<Cinchy SSO URL>/identity/connect/token
The Post Request will return an access token which can be used to access Cinchy APIs.
200: The request is successful
400: For invalid parameters, a 400 error will be returned with the following JSON response with a description of the error.
Example:
To get a bearer token from Cinchy, you can provide either:
Username and password (username
, password
), or
SAML token (token
)
Failure to provide a valid set of one of the above will not return a token.
Name | Data Type | |
---|---|---|
Name | Data Type | Description |
---|---|---|
Name | Data Type | Description |
---|---|---|
CompressJSON
boolean
Default is true. Add this parameter and set to false if you want the JSON that is returned to be expanded rather than having the schema being returned separately.
ResultFormat
string
XML
JSON
CSV
TSV
PSV
PROTOBUF
Type
string
QUERY - Query (Approved Data Only) DRAFT_QUERY - Query (Include Draft Changes) SCALAR - Scalar NONQUERY - Non Query, such as an insert or delete VERSION_HISTORY_QUERY - Query (Include Version History)
ConnectionId
string
TransactionId
string
When one or more requests share the same TransactionId, they are considered to be within the scope of a single transaction.
Query
string
The CQL query statement to execute
Parameters
boolean
See below on format for the parameters.
SchemaOnly
integer
Defaults to false.
StartRow
integer
When implementing pagination, specify a starting offset. Combine with RowCount
to set the size of the data window.
RowCount
integer
When implementing pagination, specify the number of rows to retrieve for the current page. Combine with StartRow
to set the paging position.
CommandTimeout
string
Use this parameter to override the default timeout (30s) for long running queries. In seconds.
UserId
string
Authorization
string
Bearer <access_token>. See Authentication for details.
Query String Parameter Name
Content
Parameters[n].ParameterName
Name of the parameter that is in your query, including the '@'.
Ex. @name
Parameters[n].XmlSerializedValue
XML Serialized version of the value of that parameter.
Ex. "test"
Parameters[n].ValueType
Datatype of the value.
Ex. System.String
Column
Description
Client Id
A unique identifier for each client. The client will use this identifier when retrieving a bearer token.
Client Name
A friendly name for the client to help users maintaining this record.
Grant Type
The OAuth 2.0 flow that will be used during authentication. "Resource Owner Password" should be selected for API calls.
Permitted Login Redirect URLs
N/A for the Resource Owner Password flow - leave this blank
Permitted Logout Redirect URLs
N/A for the Resource Owner Password flow - leave this blank
Permitted Scopes
The list of permitted OAuth scopes, please check all available options.
Access Token Lifetime (seconds)
The time after with the token expires. If left blank, the default is 3600 seconds.
Show Cinchy Login Screen
N/A for the Resource Owner Password flow
Enabled
This is used to enable or disable a client
Guid
This is a calculated field that will auto-generate the client secret
Content-Type
string
application/x-www-form-urlencoded
token
string
You can pass in your base64 encoded SAML token instead of your Cinchy username and password
client_id
string
Client Id value from Integrated Clients table
client_secret
string
Guid value from Integrated Clients table
username
string
Username of Cinchy user
password
string
Password for Cinchy user in plain text
grant_type
string
Set as "password" for username/password authentication. Set as "saml2" for saml token authentication.
scope
string
Set as "js_api"