uniprot logo

Forthcoming changes

Table of contents

Moving from HTTP to HTTPS

On June 20, 2018

To improve security and privacy, we are moving our web pages and services from HTTP to HTTPS.

The HTTP protocol does not provide encryption – anyone who can see web traffic between a client (e.g. a web browser) and a server can intercept potentially sensitive information and/or inject malware into users’ browsers or operating systems. HTTPS solves this problem by encrypting web traffic between a client and a server in both directions, so that observers cannot intercept or tamper with the client’s requests or the server’s responses. It also provides authentication, ensuring that the client is communicating with the intended server given by the hostname, and not some impostor.


We will support separate HTTP and HTTPS services until release 2018_06 (June 20, 2018). From this date, the HTTP traffic will be automatically redirected to HTTPS. We intend to maintain these redirects indefinitely, but it is to your advantage to update your applications to use HTTPS as soon as possible, both for performance and security reasons.

Interactive users

If you access our pages only through a Web browser (like Chrome, Firefox, Safari, Internet Explorer, Opera, etc.), the only change after the switchover date is that a green lock icon should appear inside the URL box of your browser, and the web addresses of the pages you visit will start with https://. If you are concerned about the warnings that some recent versions of Web browsers display for HTTP sites, you can already start using our HTTPS URLs now and update your bookmarks and links accordingly.

Programmatic users

If you maintain software that uses our Web APIs, you should act before the switchover date to ensure uninterrupted service. Applications that access web servers using http:// URLs instead of https:// URLs may fail after a switch to HTTPS for the following reasons:

  • Your programming environment’s HTTP facility does not automatically follow redirects from HTTP to HTTPS. Some libraries follow redirections from HTTP to HTTPS, others do not (e.g. Java’s URLConnection).
  • Your application uses HTTP requests other than GET and HEAD. These requests (including especially POST and PUT) will fail with HTTP 403 Forbidden after the switchover date.
  • Your application accesses our servers through a proxy. Check with your proxy vendor about HTTPS support and how to add or update certificates.
  • Your programming environment does not support HTTPS.

After the switchover date, our servers will:

  • Respond with a server-side redirect (HTTP 301 Moved permanently) to the corresponding HTTPS URL for HTTP GET and HEAD requests
  • Respond with HTTP 403 Forbidden and an error message to all HTTP requests other than GET and HEAD (including and especially HTTP POST).

To ensure that your applications work before and after the switchover, update them as soon as possible so that URLs for all requests to our servers start with https:// instead of http://, with the exception of URLs that start with http://purl.uniprot.org/, which are used as URIs in the UniProt RDF distribution and SPARQL service. They will be redirected to the corresponding HTTPS web page when used in a web context.

Deprecation of legacy REST URLs /batch and /mapping - please replace by /uploadlists

On June 20, 2018

Programmatic access to our “Retrieve/IDmapping” service should be addressed to the URL path /uploadlists as shown in the code examples in the respective service help pages ID mapping and Batch retrieval.

If you have existing code for batch retrieval, you will also have to specify that you are mapping to and from UniProtKB, i.e.

'from' => 'ACC+ID',
'to' => 'ACC',

(See the Perl code example in Batch retrieval.)

The obsolete URL paths /batch and /mapping are being deprecated and will no longer be supported as of release 2018_06.