Technical Overview

About the Web APIs

Through the APIs your applications can retrieve and update content in SLU Swedish Species Information Centre´s different systems.

APIs

Species Observations - multiple data resources

Species Observation System collects species observations from a number of data sources and gives the user an opportunity to search for those observations using a single API. The system contains over 100 million species observations. API documentation.

Documentation links
- GitHub repository (source code and documentation)
- Observation object
- Search filter parameters
- FAQ

Artportalen - Species Observations (www.artportalen.se)

The APIs are available in two forms. The first form includes solely read (out) APIs (used for searching observations in Artportalen), while the other form contains both read and write (in) APIs (for searching and reporting data to Artportalen. Both forms are available in test (sandbox) and production environments. Applications (apps) are first developed in the test environment and afterwards moved to the production environment after approval by SLU Swedish Species Information Centre. API Documentation-Read, API Documentation-Read and Write.

Dyntaxa Taxon Service API

Get taxonomic information from the Swedish taxonomic database, Dyntaxa. API documentation.

Dyntaxa Taxon List Service API

Get nature conservation lists. E.g. Red listed species, Alien species, Protected species. API documentation.

Artfakta - Species information

This API returns species related information from the Artfakta platform. API documentation.

Links

API Documentation
Om SLU Artdatabankens API:er (in Swedish)
API för inrapportering (in Swedish)

Security

Subscription key

To access any of the API:s an subscription key must be added to your request. Key are received by signing-in and requesting a subscription to any of the SLU Swedish Species Information Centre´s products. The keys are than found in your profile in the developer portal.

A key must always be added to any requests to the API:s. The key should be added as a HTTP request header:

Ocp-Apim-Subscription-Key: {key} or in the query string ?Subscription-Key={key}

Authorization

Requests to the SLU Swedish Species Information Centre´s Web API:s may also require authorization, ie the end user must have granted permission for an application to access/change data on behalf of the user. The application requests the permission by redirecting the user to the Login Service web application, which returns an authorization token to the application. To prove that the user was granted permission for the application, an HTTP header, with a valid authorization token, should be sent in each request to the API by the application.

Authorization: Bearer {authentication token}

OAuth 2 and OpenID Connect

The Web API uses the OAuth 2 and OpenID Connect standards during authorization.

As the first step towards authorization, you will need to receive your unique client ID and client secret key from SLU Swedish Species Information Centre to use in the authorization flows. You will also need to specify the return URL where the token should be delivered on login. Contact support to exchange authorization details.

Supported Authorization Flows

Implicit Grant flow

Implicit grant flow is implemented when clients are regarded as “insecure”, ie web clients, mobile apps etc.

Authorization Code Grant Flow with PKCE

This method is suitable for long-running applications which the user logs into once. It provides an access token that can be refreshed. Since the token exchange involves sending your secret key, this should happen on a secure location, like a backend service, not from a client like a browser or mobile app.

These flows are described in [RFC-6749] and [RFC-7636].

Name URL
OAuth 2.0 Server https://ids.artdatabanken.se
Auth URL https://ids.artdatabanken.se/connect/authorize
Access token URL https://ids.artdatabanken.se/connect/token

API

Web API endpoint documentation

The different API endpoints are documented here.

Requests

The Web APIs are based on the REST principles: data resources are accessed via standard HTTPS requests in UTF-8 format to an API endpoint. Where possible, the API strives to use the appropriate HTTP verbs for each action:

VERB DESCRIPTION
GET Used for retrieving resources
POST Used for creating resources and retrieving resources
PUT Used for changing/replacing resources or collections
DELETE Used for deleting resources

Responses

Unless otherwise stated all data is received as a JSON object.

Response Status Codes

The API uses the following response status codes:

STATUS CODE DESCRIPTION
200 OK – The request has succeeded. The client can read the result of the request in the body and the headers of the response.
204 No content - The requested resource doesn't exist.
400 Bad request – The request could not be understood by the server or the provided parameters are out of limit.
401 Unauthorized – The request requires user authentication or – if the request included authorization credentials – authorization has been denied access for those credentials.
500 Internal server error