API Authentication

From Charitylog Manual
Revision as of 14:35, 24 July 2020 by Rduheaume (talk | contribs) (Creating an Excel File to use as a central source for Power Queries)
Jump to: navigation, search

Go to API overview

Helpheader small.png

API Access Overview

API access requires being a user of the system. A user in this context is anyone who has access to your data. Each user has a 2 tabs on their record which control this:

  • The Website and Call-round Access tab controls access to your data via our website, and/or our mobile app, Call Round.
  • The 3rd Party Systems tab controls the access to your data that other systems have via the API

Using this approach, there are 3 possibilities:

  • Website/Call-round access only. This will be most users of the system doing day-to-day tasks
  • API access only. This could be to migrate data in from other systems, reporting dashboards etc
  • Both. An example of this would be if Alice sometimes logs in via the website, and sometimes using a 3rd party app. Alice's access controls are the same in both situations, i.e. she will have the same access to branches, projects and fields.

API Keys

Instead of a user name and password, the API grants access based on three headers:

  • Source. Identifies the 3rd party software provider. If Example Software Ltd supplies a number of Dizions clients, they will use the same Source key for all requests. The Source key is provided, and periodically updated, via text message.
  • Org. Identifies the charity or company, and the system type. So Example Charity's Live system will have a different Org key to Example Charity's Training system. The Org key can be viewed on the 3rd Party Systems tab of the user record in the web application.
  • User. Identifies the user within the charity or company. The User key can be created or changes on the 3rd Party Systems tab of the user record in the web application.

If you want to test that you have the keys correct, it's useful to GET https://api.dizions.co.uk/v2/dictionary, because it does not apply any access checks beyond checking the keys are correct.

Managing users

The settings on a user record (User Group, project access, branch access etc.) control what a user can see and do. This is broadly the same whether the user is using the website or the API. Remember, that as a system administrator, you are responsible for controlling who has access to your data, whether via the website, Call-round or a 3rd party application. Switching off a user is the same regardless - make them inactive on their General Details tab. To create a new API user:

* In the web application, click the Settings Cog > User Access > Users. Click Create New User
* Fill in the General User Details as normal
* On the Website Access tab, consider un-ticking the Charitylog / Crossdata if you want this user to only access your data through the API. Currently, a user name and password are still required, even if the user has no website access. In the case, they can be made-up, and immediately forgotten. Removing the tick from their website access would prevent them logging in, even if they knew their password.
* Save the record
* On the 3rd Party Systems tab, tick the box for the name of the integration that you want to use. This will generate the Org and User keys for the other application.

Using Excel to store credentials for Power Query

If we are going to use Excel for Power Query, we can create a source file to store key information;

  • Source Key
  • Organisation Key
  • User Key
  • Host