Infura IPFS Documentation (1.0.0)

Infura Support: support@infura.io

Getting started

Create your Infura IPFS project

To manage your IPFS data, you need to register your account and set up your project.

After the registration, you will be redirected to the settings page, where you will find your project's credentials to authenticate your API calls with: PROJECT_ID and PROJECT_SECRET.

Add a file

curl -X POST -F file=@myfile \
-u "PROJECT_ID:PROJECT_SECRET" \
"https://ipfs.infura.io:5001/api/v0/add"

> {
      "Name":"ipfs_file_docs_getting_started_demo.txt",
      "Hash":"QmeGAVddnBSnKc1DLE7DLV9uuTqo5F7QbaveTjr45JUdQn",
      "Size":"44"
  }

When you add a file using the /api/v0/add endpoint, the file is automatically pinned, and it isn't necessary to pin again.

Pin a file

Do you want to ensure that some file on IPFS is always available? Pin it to your PROJECT. Infura will copy it, store it, and keep it online on the IPFS P2P network.

curl -X POST -u "PROJECT_ID:PROJECT_SECRET" \
"https://ipfs.infura.io:5001/api/v0/pin/add?arg=QmeGAVddnBSnKc1DLE7DLV9uuTqo5F7QbaveTjr45JUdQn"

A pinned file will appear in your project's dashboard explorer and can be un-pinned at any time either using the unpin button in the UI or via the following /pin/rm endpoint.

Unpin a file

curl -X POST -u "PROJECT_ID:PROJECT_SECRET" \
"https://ipfs.infura.io:5001/api/v0/pin/rm?arg=QmeGAVddnBSnKc1DLE7DLV9uuTqo5F7QbaveTjr45JUdQn"

Read a file using the API

curl -X POST -u "PROJECT_ID:PROJECT_SECRET" \
"https://ipfs.infura.io:5001/api/v0/cat?arg=QmeGAVddnBSnKc1DLE7DLV9uuTqo5F7QbaveTjr45JUdQn"

> Infura IPFS - Getting started demo.

Arguments

Arguments are added through the special query string key arg:

curl -X POST "https://ipfs.infura.io:5001/api/v0/cat?arg=QmeGAVddnBSnKc1DLE7DLV9uuTqo5F7QbaveTjr45JUdQn"

Note that arg can be used multiple times to signify multiple arguments.

Flags

Flags commonly used with the IPFS CLI are added through the query string. For example, the --encoding=json flag is the &encoding=json query parameter below:

> curl -X POST "https://ipfs.infura.io:5001/api/v0/object/get?arg=QmaaqrHyAQm7gALkRW8DcfGX3u8q9rWKnxEMmf7m9z515w&encoding=json"
{
  "Links": [
    {
      "Name": "index.html",
      "Hash": "QmYftndCvcEiuSZRX7njywX2AGSeHY2ASa7VryCq1mKwEw",
      "Size": 1700
    },
    {
      "Name": "static",
      "Hash": "QmdtWFiasJeh2ymW3TD2cLHYxn1ryTuWoNpwieFyJriGTS",
      "Size": 2428803
    }
  ],
  "Data": "CAE="
}

::: tip Some arguments may belong only to the CLI but appear here too. These usually belong to client-side processing of input, particularly in the add command. :::

HTTP status codes

Status codes used at the RPC layer are simple:

  • 200 - The request was processed or is being processed (streaming)
  • 500 - RPC endpoint returned an error
  • 400 - Malformed RPC, argument type error, etc
  • 403 - RPC call forbidden
  • 404 - RPC endpoint doesn't exist
  • 405 - HTTP Method Not Allowed

Status code 500 means that the requested RPC function does exist, but IPFS was not able to fulfill the request because of an error. To know the reason, you have to look at the error message that is usually returned with the body of the response (if no error, check application logs).

Streaming endpoints fail as above, unless they have started streaming. That means they will have sent a 200 status code already. If an error happens during the stream, it will be included in a Trailer response header (some endpoints may additionally include an error in the last streamed object).

A 405error may mean that you are using the wrong HTTP method (i.e. GET instead of POST), or that you are not allowed to call that method (i.e. due to CORS restrictions when making a request from a browser).

Authentication

Overview

The Infura IPFS API is compatible with the official IPFS API. Same HTTP endpoints, flags, arguments. The only additional step you must take when interacting with the Infura API is to configure the correct Basic Authentication header.

Authorization: Basic <base64(USERNAME:PASSWORD)>

The credentials are a base64-encoded string combination of a username and password, where the username is your PROJECT_ID and password is the PROJECT_SECRET. You will find your credentials in your project's settings page after you register your Infura account and create a new project.

Below are some examples of how to execute an authenticated Infura IPFS API call.

Using cURL

cURL generates the auth header and encodes your credentials behind the scenes. All you have to do is specify the -u flag.

curl -X POST -F file=@myfile -u "PROJECT_ID:PROJECT_SECRET" "https://ipfs.infura.io:5001/api/v0/add"

Using Javascript

If you already have an existing project making IPFS API calls developed in JS, wrap your calls and decorate them with a new Infura Authorization header. Everything else stays the same, as the Infura API is fully compatible with IPFS.

xhr.setRequestHeader("Authorization", "Basic " + btoa(PROJECT_ID + ":" + PROJECT_SECRET));

Using NodeJS

Here is a complete example you can copy-paste and execute using NodeJS. Change the projectId, projectSecret to match yours.

const https = require('https')

const projectId = '1qmt...XXX'
const projectSecret = 'c920...XXX'

const options = {
  host: 'ipfs.infura.io',
  port: 5001,
  path: '/api/v0/pin/add?arg=QmeGAVddnBSnKc1DLE7DLV9uuTqo5F7QbaveTjr45JUdQn',
  method: 'POST',
  auth: projectId + ':' + projectSecret
}

let req = https.request(options, (res) => {
  let body = ''
  res.on('data', function (chunk) {
    body += chunk
  })
  res.on('end', function () {
    console.log(body)
  })
})
req.end()

Using ipfs-http-client in JS

You can also use the official js-ipfs/ipfs-http-client library!

const ipfsClient = require('ipfs-http-client')

const projectId = '1qmt...XXX'
const projectSecret = 'c920...XXX'
const auth =
  'Basic ' + Buffer.from(projectId + ':' + projectSecret).toString('base64')

const client = ipfsClient({
  host: 'ipfs.infura.io',
  port: 5001,
  protocol: 'https',
  headers: {
    authorization: auth
  }
})

client.pin.add('QmeGAVddnBSnKc1DLE7DLV9uuTqo5F7QbaveTjr45JUdQn').then((res) => {
  console.log(res)
})

Using go-ipfs-api in Go

Backend developers interacting with IPFS API via the ipfs/go-ipfs-api library can include the Infura auth header by implementing the following http.RoundTripper wrapper.

package main

import (
    "fmt"
    "net/http"
    "os"
    "strings"

    ipfsApi "github.com/ipfs/go-ipfs-api" // v0.2.0
)

func main() {
    projectId := "1qmt...XXX"
    projectSecret := "c920...XXX"

    shell := ipfsApi.NewShellWithClient("https://ipfs.infura.io:5001", NewClient(projectId, projectSecret))
    cid, err := shell.Add(strings.NewReader("Infura IPFS - Getting started demo."))
    if err != nil {
        fmt.Println(err)
        os.Exit(1)
    }

    fmt.Printf("Data successfully stored in IPFS: %v\n", cid)
}

// NewClient creates an http.Client that automatically perform basic auth on each request.
func NewClient(projectId, projectSecret string) *http.Client {
    return &http.Client{
        Transport: authTransport{
            RoundTripper:  http.DefaultTransport,
            ProjectId:     projectId,
            ProjectSecret: projectSecret,
        },
    }
}

// authTransport decorates each request with a basic auth header.
type authTransport struct {
    http.RoundTripper
    ProjectId     string
    ProjectSecret string
}

func (t authTransport) RoundTrip(r *http.Request) (*http.Response, error) {
    r.SetBasicAuth(t.ProjectId, t.ProjectSecret)
    return t.RoundTripper.RoundTrip(r)
}

Using go-ipfs-http-client in Go

For developers using the newer ipfs/go-ipfs-http-client library, here is a full example of how to authenticate your requests.

package main

import (
    "context"
    "encoding/base64"
    "fmt"
    "net/http"
    "os"
    "strings"

    ipfsFiles "github.com/ipfs/go-ipfs-files" // v0.0.8
    ipfsApi "github.com/ipfs/go-ipfs-http-client" // v0.1.0
)

func main() {
    projectId := "1qmt...XXX"
    projectSecret := "c920...XXX"

    httpClient := &http.Client{}
    httpApi, err := ipfsApi.NewURLApiWithClient("https://ipfs.infura.io:5001", httpClient)
    if err != nil {
        fmt.Println(err)
        os.Exit(1)
    }
    httpApi.Headers.Add("Authorization", "Basic " + basicAuth(projectId, projectSecret))

    content := strings.NewReader("Infura IPFS - Getting started demo.")
    p, err := httpApi.Unixfs().Add(context.Background(), ipfsFiles.NewReaderFile(content))
    if err != nil {
        fmt.Println(err)
        os.Exit(1)
    }

    fmt.Printf("Data successfully stored in IPFS: %v\n", p.Cid().String())
}

func basicAuth(projectId, projectSecret string) string {
    auth := projectId + ":" + projectSecret
    return base64.StdEncoding.EncodeToString([]byte(auth))
}

Project Security

Security settings for your project are available in the dashboard by clicking "Settings" and then the "Security" tab.

Securing With Allowlists

If you are sending API requests from a web browser or other client-side application which does not have the ability to secure your Project Secret, allowlisting can be used to prevent a third party from using your Project ID on another website.

Infura's IPFS API allows you to restrict requests by IP address, HTTP User-Agent, and HTTP Origin.

Understanding Allowlist Behavior

  • If a project has no allowlists enabled, any request will be accepted.
  • As soon as any allowlist entries are added, all requests must pass each allowlist type.
  • A maximum of 30 allowlist entries per type are allowed per project.
  • Each allowlist type is "AND"ed together
  • Multiple entries of the same type are "OR"ed.

Example

Scenario: Alice allowlisted the User-Agent of her mobile application and the Origin where her web app is hosted.

User-Agent Allowlist entry: com.example.aliceapp

Origin Allowlist Entry: aliceapp.example.com

Result: Both Alice's mobile app AND her website are allowed to use the same Project ID. If Alice created a new website under aliceawesomeapp.example.com, she would need to add this new Origin to the allowlist to allow the Project ID to function on the new site. Alternatively, she could set a single Origin in the allowlist entry to use a wildcard subdomain pattern such as *.example.com which would allow all requests matching the pattern yet reject requests from origins not matching *.example.com.

IP Addresses

In order to prevent unauthorized applications or users from using your project to make requests, you can specify the IP addresses from which requests can be made. You can either specify a single IP address (e.g. 1.1.1.1) or a range of IP addresses (e.g 1.1.1.1-2.2.2.2). If there are entries in this allowlist, then requests from IP addresses that do not match at least one of them will be rejected.

Example

Allowlist entry: 1.1.1.1

Request's IP address: 1.1.1.2

Result: Request is rejected, since it does not originate from the allowed IP address.

Example

Allowlist entry: 1.1.1.1-2.2.2.2

Request's IP address: 1.1.1.2

Result: Request is allowed, since it originates from an IP address in the allowed range.

User-Agents

If you are distributing a product which embeds an API key and you have the ability to set a custom User-Agent (e.g. an Electron app, iOS or Android app), we recommend adding the known User-Agent to your allowlist.

When a User-Agent is added to the allowlist, any API requests which originate from other platforms will be rejected.

Matching Behavior

The User-Agent allowlist utilizes partial string matching. If the allowlisted string is present in the request's full User-Agent, it is registered as a match.

Example

Allowlist entry: com.example.dapp

Request's User-Agent: com.example.dapp/v1.2.1 (Linux; Android 7.0; SM-G930V Build/NRD90M) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.125 Mobile Safari/537.36

Result: Request is allowed and all other user-agent requests are rejected

HTTP Origin

To prevent a third party from using your Project ID on their website, you can allowlist approved HTTP Origins from where the Project ID can be used.

If you are deploying your application to mydapp.example.com, adding mydapp.example.com to your HTTP Origin allowlist will ensure any traffic that does not include Origin: mydapp.example.com in the HTTP request will be rejected.

Matching Behavior

HTTP Origin matching supports wildcard subdomain patterns similarly to TLS certificates, where the left-most sub-domain may be a replaced with the special * wildcard to match any subdomain. The * matches a single sub-domain, and can only appear as the left-most portion of an entry.

The URL schema is optional, and can be either http://, https:// or any other schema you want to limit. If the schema is included in the allow list entry, then the Origin must have the same schema. Furthermore, an entry with only a schema will limit requests to Origins of that schema.

Example

Allowlist entry: https://*.example.com

Request's Origin Header: https://myapp.example.com

Result: The request above is is allowed, as both the schema and domain name match. Any requests from origins not matching https://*.example.com are rejected. This would include http://myapp.example.com (non-matching schema), https://myapp.somewhereelse.net (base domain does not match) or https://subdomain.myapp.example.com (wildcard can only match one level of sub-domains).

Quotas

You can control 3 monthly quotas from your project's settings page:

  • Storage quota: maximum allowed total storage (e.g: 0.001 GB)
  • Data transfer UP quota: maximum allowed data/month sent to the IPFS service (e.g: 0.001 GB)
  • Data transfer DOWN quota: maximum allowed data/month retrieved from the IPFS service (e.g: 0.001 GB)

If you set it to zero, you completely disable that function (for example, zero transfer up means you can’t add any data). If you clear the field and submit, there is no quota set anymore.

add

add

Add a file or directory to IPFS.

Authorizations:
query Parameters
quiet
boolean

Write minimal output. Required: no.

quieter
boolean

Write only final hash. Required: no.

silent
boolean

Write no output. Required: no.

progress
boolean

Stream progress data. Required: no.

trickle
boolean

Use trickle-dag format for dag generation. Required: no.

only-hash
boolean

Only chunk and hash - do not write to disk. Required: no.

wrap-with-directory
boolean

Wrap files with a directory object. Required: no.

chunker
string
Default: "size-262144"

Chunking algorithm, size-[bytes], rabin-[min]-[avg]-[max] or buzhash. Default: size-262144. Required: no.

pin
boolean
Default: "true"

Pin this object when adding. Default: true. Required: no.

raw-leaves
boolean

Use raw blocks for leaf nodes. (experimental). Required: no.

nocopy
boolean

Add the file using filestore. Implies raw-leaves. (experimental). Required: no.

fscache
boolean

Check the filestore for pre-existing blocks. (experimental). Required: no.

cid-version
integer <int32>
Default: null

CID version. Defaults to 0 unless an option that depends on CIDv1 is passed. (experimental). Required: no.

hash
string
Default: "sha2-256"

Hash function to use. Implies CIDv1 if not sha2-256. (experimental). Default: sha2-256. Required: no.

inline
boolean

Inline small blocks into CIDs. (experimental). Required: no.

inline-limit
integer <int32>
Default: 32

Maximum block size to inline. (experimental). Default: 32. Required: no.

Request Body schema: multipart/form-data

Argument path is of file type. This endpoint expects one or several files (depending on the command) in the body of the request as 'multipart/form-data'.

The add command not only allows adding files, but also uploading directories and complex hierarchies.

This happens as follows: Every part in the multipart request is a directory or a file to be added to IPFS.

Directory parts have a special content type application/x-directory. These parts do not carry any data. The part headers look as follows:

Content-Disposition: form-data; name="file"; filename="folderName"
Content-Type: application/x-directory

File parts carry the file payload after the following headers:

Abspath: /absolute/path/to/file.txt
Content-Disposition: form-data; name="file"; filename="folderName%2Ffile.txt"
Content-Type: application/octet-stream

...contents...

The above file includes its path in the "folderName/file.txt" hierarchy and IPFS will therefore be able to add it inside "folderName". The parts declaring the directories are optional when they have files inside and will be inferred from the filenames. In any case, a depth-first traversal of the directory tree is recommended to order the different parts making the request.

The Abspath header is included for filestore/urlstore features that are enabled with the nocopy option and it can be set to the location of the file in the filesystem (within the IPFS root), or to its full web URL.

object

Responses

Request samples

curl -X POST -F [email protected] "https://ipfs.infura.io:5001/api/v0/add?quiet=<value>&quieter=<value>&silent=<value>&progress=<value>&trickle=<value>&only-hash=<value>&wrap-with-directory=<value>&chunker=size-262144&pin=true&raw-leaves=<value>&nocopy=<value>&fscache=<value>&cid-version=<value>&hash=sha2-256&inline=<value>&inline-limit=32"

Response samples

Content type
application/json
{
  • "Bytes": 0,
  • "Hash": "string",
  • "Name": "string",
  • "Size": "string"
}

block

block_get

Get a raw IPFS block.

Authorizations:
query Parameters
arg
required
string

The base58 multihash of an existing block to get. Required: yes.

Responses

Request samples

curl -X POST "https://ipfs.infura.io:5001/api/v0/block/get?arg=<key>"

Response samples

Content type
application/json
{ }

block_put

Store input as an IPFS block.

Authorizations:
query Parameters
format
string

cid format for blocks to be created with. Required: no.

mhtype
string
Default: "sha2-256"

multihash hash function. Default: sha2-256. Required: no.

mhlen
integer <int32>
Default: -1

multihash hash length. Default: -1. Required: no.

pin
boolean
Default: "false"

pin added blocks recursively. Default: false. Required: no.

Request Body schema: multipart/form-data

Argument data is of file type. This endpoint expects one or several files (depending on the command) in the body of the request as 'multipart/form-data'.

object

Responses

Request samples

curl -X POST -F [email protected] "https://ipfs.infura.io:5001/api/v0/block/put?format=<value>&mhtype=sha2-256&mhlen=-1&pin=false"

Response samples

Content type
application/json
{
  • "Key": "string",
  • "Size": 0
}

block_stat

Print information of a raw IPFS block.

Authorizations:
query Parameters
arg
required
string

The base58 multihash of an existing block to stat. Required: yes.

Responses

Request samples

curl -X POST "https://ipfs.infura.io:5001/api/v0/block/stat?arg=<key>"

Response samples

Content type
application/json
{
  • "Key": "string",
  • "Size": 0
}

cat

cat

Show IPFS object data.

Authorizations:
query Parameters
arg
required
string

The path to the IPFS object(s) to be outputted. Required: yes.

offset
integer <int64>

Byte offset to begin reading from. Required: no.

length
integer <int64>

Maximum number of bytes to read. Required: no.

Responses

Request samples

curl -X POST "https://ipfs.infura.io:5001/api/v0/cat?arg=<ipfs-path>&offset=<value>&length=<value>"

Response samples

Content type
application/json
{ }

dag

dag_get

Get a dag node from IPFS.

Authorizations:
query Parameters
arg
required
string

The object to get Required: yes.

Responses

Request samples

curl -X POST "https://ipfs.infura.io:5001/api/v0/dag/get?arg=<ref>"

Response samples

Content type
application/json
{ }

dag_put

Add a dag node to IPFS.

Authorizations:
query Parameters
format
string
Default: "cbor"

Format that the object will be added as. Default: cbor. Required: no.

input-enc
string
Default: "json"

Format that the input object will be. Default: json. Required: no.

pin
boolean

Pin this object when adding. Required: no.

hash
string
Default: ""

Hash function to use. Default: . Required: no.

Request Body schema: multipart/form-data

Argument object data is of file type. This endpoint expects one or several files (depending on the command) in the body of the request as 'multipart/form-data'.

object

Responses

Request samples

curl -X POST -F [email protected] "https://ipfs.infura.io:5001/api/v0/dag/put?format=cbor&input-enc=json&pin=<value>&hash=<value>"

Response samples

Content type
application/json
{
  • "Cid": {
    }
}

dag_resolve

Resolve IPLD block.

Authorizations:
query Parameters
arg
required
string

The path to resolve Required: yes.

Responses

Request samples

curl -X POST "https://ipfs.infura.io:5001/api/v0/dag/resolve?arg=<ref>"

Response samples

Content type
application/json
{
  • "Cid": {
    },
  • "RemPath": "string"
}

get

get

Download IPFS objects.

Authorizations:
query Parameters
arg
required
string

The path to the IPFS object(s) to be outputted. Required: yes.

output
string

The path where the output should be stored. Required: no.

archive
boolean

Output a TAR archive. Required: no.

compress
boolean

Compress the output with GZIP compression. Required: no.

compression-level
integer <int32>

The level of compression (1-9). Required: no.

Responses

Request samples

curl -X POST "https://ipfs.infura.io:5001/api/v0/get?arg=<ipfs-path>&output=<value>&archive=<value>&compress=<value>&compression-level=<value>"

Response samples

Content type
application/json
{ }

object

object_data

Output the raw bytes of an IPFS object.

Authorizations:
query Parameters
arg
required
string

Key of the object to retrieve, in base58-encoded multihash format. Required: yes.

Responses

Request samples

curl -X POST "https://ipfs.infura.io:5001/api/v0/object/data?arg=<key>"

Response samples

Content type
application/json
{ }

object_get

Get and serialize the DAG node named by .

Authorizations:
query Parameters
arg
required
string

Key of the object to retrieve, in base58-encoded multihash format. Required: yes.

data-encoding
string
Default: "text"

Encoding type of the data field, either "text" or "base64". Default: text. Required: no.

Responses

Request samples

curl -X POST "https://ipfs.infura.io:5001/api/v0/object/get?arg=<key>&data-encoding=text"

Response samples

Content type
application/json
{
  • "Data": "string",
  • "Links": [
    ]
}

object_put

Store input as a DAG object, print its key.

Authorizations:
query Parameters
inputenc
string
Default: "json"

Encoding type of input data. One of: {"protobuf", "json"}. Default: json. Required: no.

datafieldenc
string
Default: "text"

Encoding type of the data field, either "text" or "base64". Default: text. Required: no.

pin
boolean

Pin this object when adding. Required: no.

quiet
boolean

Write minimal output. Required: no.

Request Body schema: multipart/form-data

Argument data is of file type. This endpoint expects one or several files (depending on the command) in the body of the request as 'multipart/form-data'.

object

Responses

Request samples

curl -X POST -F [email protected] "https://ipfs.infura.io:5001/api/v0/object/put?inputenc=json&datafieldenc=text&pin=<value>&quiet=<value>"

Response samples

Content type
application/json
{
  • "Hash": "string",
  • "Links": [
    ]
}

object_stat

Get stats for the DAG node named by .

Authorizations:
query Parameters
arg
required
string

Key of the object to retrieve, in base58-encoded multihash format. Required: yes.

human
boolean

Print sizes in human readable format (e.g., 1K 234M 2G). Required: no.

Responses

Request samples

curl -X POST "https://ipfs.infura.io:5001/api/v0/object/stat?arg=<key>&human=<value>"

Response samples

Content type
application/json
{
  • "BlockSize": 0,
  • "CumulativeSize": 0,
  • "DataSize": 0,
  • "Hash": "string",
  • "LinksSize": 0,
  • "NumLinks": 0
}

pin

pin_add

Pin objects to local storage.

Authorizations:
query Parameters
arg
required
string

Path to object(s) to be pinned. Required: yes.

progress
boolean

Show progress. Required: no.

Responses

Request samples

curl -X POST "https://ipfs.infura.io:5001/api/v0/pin/add?arg=<ipfs-path>&progress=<value>"

Response samples

Content type
application/json
{
  • "Pins": [
    ],
  • "Progress": 0
}

pin_ls

List objects pinned to local storage.

Authorizations:
query Parameters
arg
string

Path to object(s) to be listed. Required: no.

type
string
Default: "all"

The type of pinned keys to list. Can be "direct", "indirect", "recursive", or "all". Default: all. Required: no.

quiet
boolean

Write just hashes of objects. Required: no.

stream
boolean

Enable streaming of pins as they are discovered. Required: no.

Responses

Request samples

curl -X POST "https://ipfs.infura.io:5001/api/v0/pin/ls?arg=<ipfs-path>&type=all&quiet=<value>&stream=<value>"

Response samples

Content type
application/json
{
  • "PinLsList": {
    },
  • "PinLsObject": {
    }
}

pin_rm

Remove pinned objects from local storage.

Authorizations:
query Parameters
arg
required
string

Path to object(s) to be unpinned. Required: yes.

Responses

Request samples

curl -X POST "https://ipfs.infura.io:5001/api/v0/pin/rm?arg=<ipfs-path>"

Response samples

Content type
application/json
{
  • "Pins": [
    ]
}

pin_update

Update a recursive pin.

Authorizations:
query Parameters
arg
required
string

Path to old object. Required: yes.

arg
required
string

Path to a new object to be pinned. Required: yes.

unpin
boolean
Default: "true"

Remove the old pin. Default: true. Required: no.

Responses

Request samples

curl -X POST "https://ipfs.infura.io:5001/api/v0/pin/update?arg=<from-path>&arg=<to-path>&unpin=true"

Response samples

Content type
application/json
{
  • "Pins": [
    ]
}

version

version

Show IPFS version information.

Authorizations:
query Parameters
number
boolean

Only show the version number. Required: no.

commit
boolean

Show the commit hash. Required: no.

repo
boolean

Show repo version. Required: no.

all
boolean

Show all version information. Required: no.

Responses

Request samples

curl -X POST "https://ipfs.infura.io:5001/api/v0/version?number=<value>&commit=<value>&repo=<value>&all=<value>"

Response samples

Content type
application/json
{
  • "Commit": "string",
  • "Golang": "string",
  • "Repo": "string",
  • "System": "string",
  • "Version": "string"
}