> ## Documentation Index > Fetch the complete documentation index at: https://docs.brickken.com/llms.txt > Use this file to discover all available pages before exploring further. # Update Token Documentation > **Description:** This endpoint allows you to update token-related documentation and branding materials. It is fully off-chain and does not prepare or require a blockchain transaction. **Headers:** - `x-api-key`: `YOUR_API_KEY` **Request Format:** This endpoint accepts `multipart/form-data` input, which should include: - `tokenSymbol` (text) - `tokenLogotype` (image file) - optional - `subscriptionAgreement` (PDF file) - optional - `legalDocs` (PDF file) - optional **What the endpoint does:** - The `tokenLogotype` is uploaded to S3. - The `subscriptionAgreement` and `legalDocs` are uploaded to IPFS. - The token record (identified by `tokenSymbol`) is then updated with references to the uploaded files. - No `txId`, transaction payload, or signed transaction is produced. **Security:** - You must provide a valid `x-api-key`. - API key requests do not require `signerAddress`. ## Overview The `PATCH /patch-token-docs` endpoint allows you to update token-related documentation and branding materials for existing tokens. This endpoint handles file uploads for token logos, subscription agreements, and legal documents. ## Key Features * **Token Logo Upload**: Upload token logotype images to S3 storage * **Legal Document Management**: Upload subscription agreements and legal documents to IPFS * **Multipart Form Data**: Supports file uploads through multipart/form-data format * **Selective Updates**: All file fields are optional - update only what you need * **Off-chain Update**: This endpoint does not prepare or require any blockchain transaction ## Request Format This endpoint accepts `multipart/form-data` with the following fields: ### Required Fields * **`tokenSymbol`** (string): The symbol of the token being updated ### Optional File Fields * **`tokenLogotype`** (image file): Logo image for the token (uploaded to S3) * **`subscriptionAgreement`** (PDF file): Subscription agreement document (uploaded to IPFS) * **`legalDocs`** (PDF file): Legal documentation (uploaded to IPFS) ## Example Request ```bash theme={null} curl -X PATCH "https://api.sandbox.brickken.com/patch-token-docs" \ -H "x-api-key: YOUR_API_KEY" \ -F "tokenSymbol=MYTOKEN" \ -F "tokenLogotype=@logo.png" \ -F "subscriptionAgreement=@agreement.pdf" \ -F "legalDocs=@legal.pdf" ``` ## Response Format ### Success Response (200) ```json theme={null} { "success": true, "tokenSymbol": "MYTOKEN", "tokenLogotypeRef": "s3://bucket/path/to/logo.png", "subscriptionAgreementIpfs": "QmXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXx", "legalDocsIpfs": "QmYyYyYyYyYyYyYyYyYyYyYyYyYyYyYyYyYyYyYy" } ``` ### Response Fields | Field | Type | Description | | --------------------------- | ------- | ----------------------------------------------------- | | `success` | boolean | Indicates if the operation was successful | | `tokenSymbol` | string | The token symbol that was updated | | `tokenLogotypeRef` | string | S3 path reference to the uploaded logo (if provided) | | `subscriptionAgreementIpfs` | string | IPFS CID for the subscription agreement (if provided) | | `legalDocsIpfs` | string | IPFS CID for the legal documents (if provided) | ## File Storage Details ### Token Logotype * **Storage**: Amazon S3 * **Supported Formats**: Image files (PNG, JPG, etc.) * **Access**: Direct S3 URL reference * **Use Case**: Token branding and display ### Legal Documents * **Storage**: IPFS (InterPlanetary File System) * **Supported Formats**: PDF files * **Access**: IPFS CID (Content Identifier) * **Use Case**: Immutable legal document storage ## Security & Authorization * **API Key Required**: Include your API key in the `x-api-key` header * **Token Ownership**: You can only update documentation for tokens associated with your account * **File Validation**: Files are validated for type and size before upload * **No Transaction Signature**: API key requests do not require `signerAddress`, `txId`, or signed transactions ## Error Handling ### Common Error Responses **400 Bad Request** ```json theme={null} { "message": "tokenSymbol is required" } ``` **401 Unauthorized** ```json theme={null} { "message": "No email found in token. Unauthorized." } ``` ## Use Cases 1. **Brand Updates**: Update token logos for better visual representation 2. **Legal Compliance**: Upload updated subscription agreements and legal documents 3. **Documentation Management**: Maintain current legal and compliance documentation 4. **Token Maintenance**: Keep token information up-to-date post-creation ## Important Notes * Only the `tokenSymbol` field is required - all file uploads are optional * Files are processed and uploaded to different storage systems based on their purpose * IPFS storage ensures immutable document storage for legal compliance * S3 storage provides fast access for branding materials * This endpoint is fully off-chain: token logos are uploaded to S3, documents are uploaded to IPFS, and the token database record is updated without preparing a blockchain transaction * The endpoint validates file types and user permissions before processing uploads ## OpenAPI ````yaml PATCH /patch-token-docs openapi: 3.1.0 info: title: Brickken API V2 description: >- Welcome to the Brickken API documentation. This API allows customers to create and manage tokenization processes, including creating new tokenizations, minting/burning/transferring tokens, whitelisting users, manage tokens approvals. This documentation provides detailed information on how to use the API, including the necessary endpoints, request formats, and expected responses.
**Authentication**All API requests require an API key for authentication. Include your API key in the `x-api-key` header of each request:
```
      x-api-key: YOUR_API_KEY
    ```
Ensure that your API key is kept secure and not shared publicly. A common parameter for all requests is the `signerAddress`. Such address MUST be whitelisted in our factory. To whitelist an address and/or request an API key either for sandbox/production environment please contact with: support@brickken.com. Once a `signerAddress` performs a `newTokenization` we refer to that address as the tokenizer. The tokenizer will be the only one allowed to mint such token, distribute dividends on such token and whitelist/blacklist investors of such token. Regarding actions like transferring tokens or burning tokens, the `signerAddress` can be any user and not only the tokenizer.
**Supported Networks & Addresses**
Sepolia (sandbox environment only)
```
      Chain Id: "aa36a7"
      Factory Address: "0x933ABAA95a7Fd0Bc683bDe2adB89f4C5EA64897b"
      BKN Address: "0x97a13487f889dc770Ac925Be2d3b6c833FA7746a"
      USDT Address: "0x28d2B01854D0aBec267a3DDcad9163580E6E8604"
      USDC Address: "0xb10cE8e28aEb1ae27b968Fb3bfed2FD7dd52daCb"
    ```
Base Sepolia (sandbox / testing)
```
      Chain Id: "84532" (hex "14a34")
      x402 USDC (Circle, EIP-3009): "0x036CbD53842c5426634e7929541eC2318f3dCF7e"
      ERC-8004 Identity Registry: "0x8004A818BFB912233c491871b3d84c89A494BD9e"
      ERC-8004 Reputation Registry: "0x8004B663056A597Dffe9eCcC1965A193B7388713"
    ```
Ethereum mainnet (production environment only)
```
      Chain Id: "1"
      Factory Address: "0x91af681C85Ca98Efc5D69C1B62E6F435030969Db"
      BKN Address: "0x0A638F07ACc6969abF392bB009f216D22aDEa36d"
      USDT Address: "0xdac17f958d2ee523a2206206994597c13d831ec7"
      USDC Address: "0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48"
    ```
Base mainnet (production environment only)
```
      Chain Id: "2105"
      Factory Address: "0x278D7bdc2451B0Fa4087A68ce084a86cB91D4d83"
      BKN Address: "0xddB293BB5C5258F7484A94a0fBd5c8B2F6E4e376"
      USDT Address: N/A
      USDC Address: "0x833589fcd6edb6e08f4c7c32d4f71b54bda02913"
    ```
BNB Smart Chain mainnet (production environment only)
```
      Chain Id: "38"
      Factory Address: "0xCe4529Fe88df480BD777d3e32dfD7032e6C685ff"
      BKN Address: "0x0e28bC9B03971E95acF9ae1326E51ecF9C55B498"
      USDT Address: "0x55d398326f99059fF775485246999027B3197955"
      USDC Address: "0x8AC76a51cc950d9822D68b83fE1Ad97B32Cd580d"
    ```
Avalance C Chain mainnet (production environment only)
```
      Chain Id: "a86a"
      Factory Address: "0xc6c230FA8F40022dE997727436Fae01caAbcDe61"
      BKN Address: "0xd44E4Dc8bdF7C1c62CfDBb182022097BA42Ac6bC"
      USDT Address: "0x9702230A8Ea53601f5cD2dc00fDBc13d4dF4A8c7"
      USDC Address: "0xB97EF9Ef8734C71904D8002F8b6Bc66Dd9c48a6E"
    ```
**Usage Workflow**
1. **Prepare Transactions:**- Use the `POST /prepare-transactions` endpoint with the desired method (e.g., `newTokenization`, `mintToken`, etc...) to prepare the transaction(s). - The response will include an array of unsigned transactions that needs to be signed.
**Example Of An Endpoint Response:**```json { "transactions": [ { "from": "0xSignerAddress", "to": "0xTargetAddress", "value": { "type": "BigNumber", "hex": "0x00" }, "nonce": 1, "chainId": 11155111, "data": "0x...", "type": 2, "maxPriorityFeePerGas": { "type": "BigNumber", "hex": "0x..." }, "maxFeePerGas": { "type": "BigNumber", "hex": "0x..." }, "gasLimit": { "type": "BigNumber", "hex": "0x..." } } ] } ```
2. **Sign the Transactions:**- Use your preferred method or wallet to sign the transaction data provided in the response. - Ensure that the signer address matches the `signerAddress` provided in the initial request.
**Example Of signing a transaction with typescript and `ethers-js`:**```typescript const tx = {...} // One of the object in the array returned by the `/prepare-transactions` endpoint const privateKey = process.env.PRIVATE_KEY; const wallet = new ethers.Wallet(privateKey); const signedTx = await wallet.signTransaction(tx); console.log('Signed Transaction:', signedTx); ```
**NOTE:** Be sure to have enough funds in the signer wallet to cover for the transaction cost
3. **Submit Signed Transactions:**- Use the `POST /send-transactions` endpoint to submit the signed transaction(s) along with the required parameters. - The API will process the transactions, send them to the blockchain, and update the Brickken database accordingly.
4. **Check Transaction Status:**- Use the `GET /get-transaction-status` endpoint to check the status of your transaction. - Provide either the on-chain transaction hash (`hash`) or the internal transaction ID (`txId`) to retrieve the status.
**Environments**The API is available in several environments for testing and production purposes:- Sandbox: `https://api.sandbox.brickken.com/` - Master (Production): `https://api.brickken.com/`
The API also exposes x402scan discovery facade endpoints under /x402/... The public discovery target is https://api.brickken.com, with /.well-known/x402 returning resource URLs and /openapi.json returning the generated OpenAPI 3.1 document. version: 2.0.0 servers: - url: https://api.sandbox.brickken.com description: Sandbox Environment - url: https://api.brickken.com description: Production Environment security: - apiKeyAuth: [] paths: /patch-token-docs: patch: tags: - Endpoints summary: Update Token Documentation description: >- **Description:** This endpoint allows you to update token-related documentation and branding materials. It is fully off-chain and does not prepare or require a blockchain transaction. **Headers:** - `x-api-key`: `YOUR_API_KEY` **Request Format:** This endpoint accepts `multipart/form-data` input, which should include: - `tokenSymbol` (text) - `tokenLogotype` (image file) - optional - `subscriptionAgreement` (PDF file) - optional - `legalDocs` (PDF file) - optional **What the endpoint does:** - The `tokenLogotype` is uploaded to S3. - The `subscriptionAgreement` and `legalDocs` are uploaded to IPFS. - The token record (identified by `tokenSymbol`) is then updated with references to the uploaded files. - No `txId`, transaction payload, or signed transaction is produced. **Security:** - You must provide a valid `x-api-key`. - API key requests do not require `signerAddress`. requestBody: required: true content: multipart/form-data: schema: type: object properties: tokenSymbol: type: string description: The symbol of the token being updated. tokenLogotype: type: object format: binary description: Image file for the token's logo. subscriptionAgreement: type: object format: binary description: PDF file for the token's subscription agreement. legalDocs: type: object format: binary description: PDF file containing the legal documentation. required: - tokenSymbol responses: '200': description: Successful update content: application/json: schema: type: object properties: success: type: boolean description: Indicates if the operation was successful. example: true tokenSymbol: type: string description: The token symbol that was updated. tokenLogotypeRef: type: string description: >- Reference (e.g., S3 path) to the uploaded token logotype image. subscriptionAgreementIpfs: type: string description: IPFS CID reference to the uploaded subscription agreement. legalDocsIpfs: type: string description: IPFS CID reference to the uploaded legal documents. '400': description: Bad Request content: application/json: schema: type: object properties: message: type: string description: Error message indicating what went wrong. '401': description: Unauthorized request (invalid or missing API key). '500': description: Internal server error. security: - apiKeyAuth: [] components: securitySchemes: apiKeyAuth: type: apiKey in: header name: x-api-key ````