Jump to navigation Jump to search

ZINC 15 uses a uniform set of rules to interpret the URL allowing both web pages and a machine-readable application programming interface (API). This page describes both.


ZINC15 queries for all resource types can be formulated as HTTP requests using a consistent URL syntax. The syntax is consistent for both interactive (browser-based) and API (script-based) queries. The API downloads are triggered by specifying a download format and, optionally, a list of output fields to include.

All URLs will be provided relative to zinc15.docking.org, thus /substances/ implies zinc15.docking.org/substances/.


The full syntax of a query is defined as:


More Concisely, this can be written as:

/<Root>[/<Subsets>][/<Existential>[/<Ext. Subsets>]]<Formatting>[?[<Constraints>][<Options>]]

Broken down into individual components:

Syntax Name Explanation Example Notes
Query Root
Defines where the query should be performed: either on the whole resource or only those related to another, single resource. /trials/NCT00001251/substances Valid values for <IDENTIFIER> and <RELATION> parts of the query root are defined separate for each resource.
subsets/<SUBSET>[+<SUBSET>...] (Subsets)
Query Subsets
Applies one or more named, predefined constraints to the query. .../subsets/fda+for-sale/ Subsets are defined separately for each resource. Some subsets are disjoint, so it's possible to accidentally construct null queries
having/[no-]<EXT_RELATION>[+[no-]<EXT_RELATION>...] (Existential)
Existential Requirements
Applies existential (or non-existential with the "no-" prefix) constraints based on on the results of the query .../having/no-protomers/ The available relations depend on the resultant resource, which is not necessarily the same as the root resource
Existential Relation Subsets
Applies subset requirements to the **existential relation requirement** (see above) of the query .../subsets/cancer/ The relation subsets are completely independent of the query subsets, and valid values depend on the type of the existential resource. When multiple existential relations are specified, the subsets must be prefixed with "<EXT_RELATION>." to identify which they apply to.
/[<VIEW>.html] OR
Formatting Options
Dictates how the result of a query will be returned. If <FORMAT> is specified the result will be sent as a download. If a <VIEW> is specified the result will be rendered as HTML. If neither is provided (just "/") the "**Accept**" header will be interrogated to determine the requested format, which defaults to HTML. .json:public_identifier+name +num_genes+num_substances Valid views (currently) include table or tile. The default is always tile. Valid ZINC15:Formats are explained in the wiki. Valid <OUTPUT_FIELD>s depend on the specific resource being requested, and can be found on the resource help pages.

Query Root

There are three basic types of queries supported by ZINC15.

Kind Syntax Description Example
Full Resource Listing /<RESOURCE> Performs the query on all <RESOURCE>s /genes
Single Resource Lookup /<RESOURCE>/<IDENTIFIER> Retrieves information about a specific <RESOURCE> instance identified by <IDENTIFIER> /genes/ADRB1
Single Resource Relation /<RESOURCE>/<IDENTIFIER>/<RELATION> Performs the query on only resources that are linked to a specific instance of a <RESOURCE> identified by <IDENTIFIER> via the <RELATION> relationship. The type of the result will depend on the taret of <RELATION> (see below). /genes/ADRB1/substances


Name Meaning Example Example URL Options
<RESOURCE> The name of a ZINC15 resource. catalogs /catalogs/ Wiki Explanation of Resources ZINC15 Meta-resource
<IDENTIFIER> The unique identifier (key) for a specific resource instance. ZINC000000000053 /substances/ZINC000000000053/ The identifier column is listed on each resources' "help" page (e.g. [1]) and can also always be accessed via the `public_identifier` attribute of a resource instance.
<RELATION> The name of a relation defined on <RESOURCE> objects. activities /substances/ZINC000000000053/activities The name and type of each resources' relations is defined on the "help" page (e.g. [2])

Note that a query rooted on /catalog/sial/items will not return **catalogs**, but instead **catitems**, as the catalog relation named **items** returns **catitem** resources. This can be seen on the Catalog Help Page.

The items in [ square brackets ] are optional. The items in < angled braces > are each described below.

  • <RESOURCE> is an object type, such as molecules, catalogs or genes, and are fully described here: ZINC15:Resources
  • <FORMAT> is one of the supported formats, such as smi, sdf, csv, fully described here: ZINC15:Formats. If a format is omitted, a webpage is implicitly requested.
  • <FIELDS> are individual properties, including calculated ones, and are described together with the ZINC15:Resources to which they belong.

ZINC15:Properties Not all properties make sense in all resource contexts. ZINC15:examples are provided. Each resource has default fields, if none are specified.

  • <ENDPOINT> is one of (tile, table, detail, etc.) (only available if the underlying template exists); where items in [ square brackets ] are optional, and:
  • <PREDICATE_LIST> is a query string, one or more of <PREDICATE> delimited by &<PREDICATE> is <ATTRIBUTE>[:<OPERATOR>[;<OPERATOR_ARGS>]]=<THRESHOLD>
  • ZINC15:Page Controls are optional, and are used to qualify how a search is to be performed and formatted for the page.
  • https is currently not supported, but it will be.

Reserved words

  • list, tile, subsets, help, overview - these have special meaning in the URL, and can never be the names of resources or their columns.


We illustrate the use of the website and the API with ZINC15:examples.

Back to ZINC15