Portal Community
These operations use the Cluster connection, not Kubo. All four require clusterBaseUrl (plus optional clusterAuthMode/destinationCredentialID) — see Connecting. They do not use baseUrl at all.

add

Binary input. Uploads content directly to the cluster for replicated pinning.

FieldTypeRequiredDefaultDescription
inputDataKeytextNodataKey in the upstream node's InputData holding the bytes to add.
dataModeselectNobase64base64 | text.
inlineContenttextNoInline content fallback.
fileNametextNofileFile name recorded on the multipart part.
replicationMinintNoMinimum replication factor across cluster peers.
replicationMaxintNoMaximum replication factor across cluster peers.
nametextNoHuman-readable pin name within the cluster.

Response: { cid, name, bytes, allocations, status }allocations lists the cluster peers the content was pinned to.

pinStatus

FieldTypeRequired
cidtext✓ Yes

Missing → CFG_MISSING_CID. Reports the per-peer replication status of a pin — which cluster peers currently hold it and their individual pin state.

unpin

FieldTypeRequired
cidtext✓ Yes

Missing → CFG_MISSING_CID. Removes a pin from the cluster (all replicas) — distinct from pin/remove, which unpins only on the single connected Kubo daemon.

listPeers

No operation-specific config beyond the shared Cluster connection. Lists the cluster's current membership.

cluster vs. pin/remote*: cluster operations talk to your own IPFS Cluster daemon, which coordinates a set of Kubo peers you control. pin/remote* operations (see Pin Operations) talk to a third-party Pinning Service API provider — a different trust boundary and a different protocol.