
AIOZ Pin for developers breaks down into three layers: a REST API with 8 distinct sections, an official Node.js SDK that wraps the most common calls into 14 methods, and a standalone CLI tool for scripting from the terminal. All three authenticate the same way, through a scoped API key you generate from your account. This guide covers how the pieces fit together, so you can pick the right layer for what you're building instead of guessing.
TL;DR:
@aioznetwork/aioz-pin-sdk) wraps common operations into methods like pinFilesToIPFS() and pinNft()The REST API is organized into 8 sections, each covering a distinct area:
| Section | Covers |
|---|---|
| Users | Account info (GET /users/me), profile updates (PUT /users/editProfile) |
| ApiKeys | Generating, listing, and revoking scoped API keys |
| Pinning | Core pin, list, and unpin operations |
| Nft | NFT-specific pinning and metadata operations |
| Gateways | Managing dedicated gateway configuration |
| Pinning Services API | The standard-compliant endpoint, covered in full in our IPFS Pinning Service API guide |
| Billing | Usage history, top-ups, and current-month spend |
| Image Optimization | On-the-fly image transforms served through the gateway |
Every request authenticates with Authorization: Bearer <access_token>. If you're building a script that only needs to pin files and never touch billing or user settings, you don't need the full picture, just the Pinning and ApiKeys sections.
Generating a key is a POST to /apiKeys with a scopes object, and the scopes are genuinely granular: admin (boolean, full access), data (with pin_list and nft_list read permissions), pinning (with unpin, pin_by_hash, and pin_file_to_ipfs permissions), and pin_nft (with unpin_nft and pin_nft_to_ipfs permissions). AIOZ Pin's docs specify that when setting permissions, you need to include all properties, admin keys are the one exception where sub-properties can be omitted.
In practice, this means a key handed to a CI pipeline that only uploads build artifacts can be scoped to pinning alone, with no ability to unpin existing content or touch NFT operations, meaningfully different from generating one admin key and using it everywhere.
The official SDK, @aioznetwork/aioz-pin-sdk (currently v1.0.1), wraps the REST API into a client object:
import AiozPinClient from '@aioznetwork/aioz-pin-sdk'
const client = new AiozPinClient('api-key', 'secret-key')
From there, the SDK covers pinning (pinFilesToIPFS(), pinFolderToIPFS(), pinByHash(), unpin()), NFTs (pinNft(), pinNftByStreamMetadata(), pinNftByHash(), pinNftByHashAndMetadataStream(), unpinNft()), and retrieval (getPinList(), getPinByID(), getPinByCID(), optimizeImage()), plus testAuthentication() to verify your keys work before you build anything on top of them. One naming note worth flagging: AIOZ's own quick-start guide writes the file-pinning method as the singular pinFileToIPFS, but the actual published package ships the plural pinFilesToIPFS(), which takes an array of file paths. Use the plural form, it's what the real package exports.
A separate command-line tool lives on the AIOZNetwork GitHub org for pinning from a shell script or CI pipeline without pulling in the Node.js SDK:
pinning login --key "your_key" --secret "your_secret"
pinning pin --file afile.txt
pinning list-pins
pinning unpin --id=00000000-0000-0000-0000-000000000000
This is the right layer if you're pinning from a build step, a cron job, or any environment where adding a Node.js dependency is more overhead than it's worth.
| Layer | Best fit | Setup cost | Language |
|---|---|---|---|
| REST API | Non-Node.js projects, or an endpoint the SDK doesn't wrap yet (like the Pinning Services API standard, meant to be called directly by IPFS-compliant tooling) | Lowest, no dependency to install | Any |
| Node.js SDK | Node.js applications wanting typed, higher-level methods instead of raw HTTP calls, especially NFT pinning where pinNft() handles asset and metadata in one call |
One npm install |
JavaScript/TypeScript |
| CLI | Shell scripts, CI pipelines, cron jobs, anywhere adding a Node.js dependency is more overhead than the task warrants | go build from source, one static binary |
Any (shell) |
All three ultimately call the same underlying REST endpoints, so this isn't a choice between different capabilities, it's a choice about which layer fits the runtime environment a given integration already lives in. A project that starts with direct REST calls in a Python data pipeline and later adds a Node.js dashboard doesn't need to reconcile two different pinning implementations, both are talking to the identical API underneath.
Whichever layer an integration uses, the same first step applies before writing any real pinning logic: confirm the credentials actually work. The SDK and CLI both expose this directly, testAuthentication() in the SDK, and the CLI's login command itself fails immediately on bad credentials rather than deferring the error to the first real pin attempt. Calling this before building anything further catches a copy-pasted key with a typo, or a key scoped incorrectly for the operation about to be attempted, at the cheapest possible point, before it's buried under application logic that makes the actual auth failure harder to spot.
What are the 8 sections of AIOZ Pin's API? Users, ApiKeys, Pinning, Nft, Gateways, Pinning Services API, Billing, and Image Optimization, each covering a distinct area of functionality.
What is the correct Node.js SDK package name? @aioznetwork/aioz-pin-sdk. The unscoped name aioz-pin-sdk shown in some AIOZ documentation does not exist as a real package.
Are AIOZ Pin API keys scoped, or is it all-or-nothing access? Scoped. You can generate a key limited to specific permissions, like pinning without unpin or billing access, rather than one master key with full access to everything.
Should I use the SDK or call the REST API directly? Use the SDK if you're in Node.js and want higher-level methods. Call the REST API directly for other languages, or for endpoints like the Pinning Services API standard that are meant to be called directly by IPFS tooling.
Does AIOZ Pin have a command-line tool? Yes, a separate CLI on the AIOZNetwork GitHub org, useful for pinning from shell scripts or CI pipelines without adding a Node.js dependency.
What's the exact method name for pinning multiple files in the SDK? pinFilesToIPFS({filePaths, options}). AIOZ's own quick-start guide shows this as the singular pinFileToIPFS, but the real published package uses the plural form.

IPFS defaults to 256 KiB fixed-size chunks, but also ships Rabin and Buzhash content-defined chunkers. Here is why the choice affects deduplication.

An IPFS CID is not a random string. It encodes a version, a codec, and a hash algorithm plus digest. Here is how to decode a real CID piece by piece.

IPFS does not use a B-tree for large directories. It uses a HAMT, a Hash Array Mapped Trie. Here is exactly how it shards a folder once it outgrows one block.

AIOZ Pin image resizing happens straight in the gateway URL, no upload step or separate service. Here is every img- parameter, with real srcset examples.

x402 payments let ERC-8004 weight a paid AI agent interaction more heavily than free work in its reputation score. Here is exactly how that link works.

AIOZ Pin NFT API calls pin an asset and its metadata as two tracked pins under one record. Here is how to automate it directly over REST, no SDK needed.