Chainlink Developers

Welcome to the Chainlink documentation site. You'll find comprehensive guides and documentation to help you start working with Chainlink as quickly as possible, as well as support if you get stuck. Click here for an introductory walkthrough on how to create a Chainlink request on the Ropsten test network!

Building on Chainlink? Click here to get started!

Get Started

Job Specifications

Job specifications, or specs, contain the sequential tasks that the node must perform to produce a final result. A spec contains at least one initiator and one task, which are discussed in detail below. Specs are defined using standard JSON so that they are human-readable and can be easily parsed by the Chainlink node.

Here is an example of a spec:

{
  "initiators": [
    {
      "type": "RunLog",
      "params": { "address": "0x51DE85B0cD5B3684865ECfEedfBAF12777cd0Ff8" }
    }
  ],
  "tasks": [
    {
      "type": "HTTPGet",
      "confirmations": 0,
      "params": { "get": "https://bitstamp.net/api/ticker/" }
    },
    {
      "type": "JSONParse",
      "params": { "path": [ "last" ] }
    },
    {
      "type": "Multiply",
      "params": { "times": 100 }
    },
    { "type": "EthUint256" },
    { "type": "EthTx" }
  ]
}

This example shows the two main components of a spec: initiators and tasks. Initiators determine how the spec will start. Tasks are the individual steps that the Chainlink node follows to process data in order to produce a result.

In the example above, we see that the only initiator is a RunLog. This means that the spec can only be started when a specific event log is emitted from a specified address. The specified address will be the address of the oracle contract on Ropsten, which manages requests from contracts and responses from Chainlink nodes.

The five tasks (referred to as adapters) in the example above follow a common pattern for requesting data from the Chainlink network, and returning a single result. Each task takes three fields: type, confirmations, and params. The type is the adapter or bridge name and is required. confirmations is optional, and will default to 0. params is also optional, and will default to an empty object if not specified. See the adapters page for a complete list of params for each adapter.

  1. The HTTPGet adapter uses the value in the get field to perform a standard HTTP GET request at the value specified. The body of that result is passed on to the next task, JSONParse.
  2. The JSONParse adapter takes a dot-delimited string or an array of strings, and will walk the given path to store the value at the end. In this case, there is only one field to save, "last". JSONParse will then pass the value stored in the "last" field to the Multiply adapter.
  3. The Multiply adapter will, as its name describes, multiply the given value by the value of the times field, in this case, 100.
  4. The multiplied value will be passed to the EthUint256 adapter, which will format it specifically for the uint256 data type on Ethereum. Notice there are no parameters supplied to the EthUint256 adapter, as it does not accept any.
  5. Finally, that formatted value is written to the blockchain with the EthTx adapter. The parameters for the EthTx adapter are given by the oracle contract when the run is initiated through the RunLog initiator.

Note: If specifying multiple adapters of the same type, the parameters can be specified in the job spec itself if the key values need to be different. The requester can also use run parameters for these requests, but shared keys will be the same for any adapter that uses them.

Job Specifications


Suggested Edits are limited on API Reference Pages

You can only suggest edits to Markdown body content, but not to the API spec.