As our access rights evolve towards a new philosophy aiming at data partitioning, some processes and analysis access will soon change. To ensure data privacy for our customers, we are progressively restricting data access to Organisations as detailed in our dedicated articles about the new access rights system. Here is a quick recap of how different scopes of data can be accessed in our affected solutions, with clickable links to check details per case:
|Dashboard||Data Query||API calls|
|Logged-in browsers||Unlogged browsers|
Single-site and Multi-site for a single organisation
All our solutions handle single-site and multi-site (from the same organisation) analysis done in Dashboard/DataQuery, or done with API calls, via either interface connexion or basic authentification.
If you are working with different companies from your AT Internet account, like in the case of agencies for instance, you can use the organisation switcher to access the company's sites as detailed in our new access rights system's articles. The organisation switcher must be used for all analyses done via a logged in browser (including Analytics Suite 2 solutions like Explorer). It is located in the top-right corner under the profile section, in the Organisation section as shown in these screenshots:
Data Query / Dashboard / Report...
Datasets can be added in three different ways in Dashboards:
- Create a dataset thanks to the dedicated section.
- Import data based on a Data Query template (single or multi-site single organisation).
- Import data from an external service and use our REST API calls.
Options 1 and 2 can only refer to the sites in the dashboard, which should be the ones picked in the Dashboard site list among the current organisation sites. Option 3 will let you import multi-site API calls from our REST API that are currently working cross-organisation. Please note that these API calls will no longer be working by 2019 as AT Internet continues to work toward data partitioning per organisation in its new analyses.
The data available in Data Query can only be based on the site list from the current organisation.
Multi-site templates are still available but will only use the sites listed in the same organisation.
- Logged in browsers
Being logged in to a browser allows you to access the API call directly. However, be careful, as your access to data will be based on the last organisation you accessed while logged in to our solutions. This means you might have to go back to Explorer and switch the current organisation to initiate your call. Please note that cross-organisation API calls work for now but will no longer be working by 2019 as mentioned above.
- Unlogged browsers (Excel/Postman...)
Data access by API calls through a third party solution requires a basic authentication. Cross-organisation API calls also work for now but should be unavailable by 2019. If your account is listed on a contract belonging to an organisation, and also in the Other organisation, this means you are listed on contracts that use different access rights systems.
This situation will only remain until all contracts have been migrated to the new Access Rights system (end of September). Until then, any access to former-access-rights-system-based contracts will have to specify -1\ before the login (-1\firstname.lastname@example.org) as in this example in Postman:
API keys for external authentications
What is an API key
An API Key is a string of characters that can be generated by a user after the authentication on the Analytic suite 2. An API Key aims at being used when querying AT Internet REST API instead of providing login details using basic authentication.
Who can create an API key
An API Key can only be created by an authenticated user who can manipulate data. This user must have at least one of the following roles:
- Advanced Analyst
- or Custom Role with the “Handle data” tool
The API Key is created, enabled, disabled and deleted by each user independently.
Using an API key
An API Key gives the same permissions than the user who created it. If the user loses rights on a site, then he won’t be able to use his API key to get data on this site anymore. If the user gets rights on a new site, then he will be able to use his API key to get data on this site.
The API Key aims at being used with REST URLs retrieved from Data Query. We invite you to use an API Key instead of providing login details using basic authentication, when querying the API with an external tool (Script or other).
If you are an SSO user, you must use an API Key to query AT Internet REST API.
How to create an API key
1. Click on « See profile »
2. Open the « API KEYS » tab
3. Click on the button « Create a new API Key »
4. Enter a name and a description
5. Click on the button « Create a new API key »
6. Copy the API Key by clicking on the Copy button and save it in a safe place
7. Confirm the action by checking the check box
Please note that for security reasons, the full API key will only be displayed once during the process described above.
A user can generate an API Key for each project/use of AT Internet REST API. To easily identify the API Key on the interface, we recommend that you give clear and accurate name and description to each API key.
How to display existing API keys
The API Keys are displayed in a table providing the user with the following information:
1. Name of the API Key
2. Description of the API key
3. First characters of the API Key
4. Creation date
5. Date of last use
6. Status of the API Key: Active/Inactive
How to modify an API key
From the table displaying all the API Keys, the user can edit each of them to:
1. Update the name or description
2. Make the API Key Inactive
As soon as an API Key is inactive, it can be deleted by the user.
Please notice that deleting an API Key is a definitive action. A deleted API Key cannot be recovered.
How to use an API key
An API key can be sent with a request header: parameter is x-api-key.
• x-api-key: e8005ef09a17_039a21e785851e51111111111130cf3157*****
Request sent using Postman
Secure your API keys
If you use API Keys, please make sure:
- To keep them in a safe place.
- To keep the use of sending the API Key in query string to the minimum.
- If you have to share an API Key with someone, create a new one with a specific name and description and then disable or delete it as soon as you can.
- To delete the useless API Keys on a regular basis.
- To renew the API Keys used in your programs on a regular basis.