> For the complete documentation index, see [llms.txt](https://trench-today.gitbook.io/trench-today/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://trench-today.gitbook.io/trench-today/for-developers/public-api.md). # Public API — Create Token The **Public API** (`papi`) lets any client build a "create token" transaction on the **Robinhood chain** without an API key. The endpoint returns the **calldata** for the transaction; the caller signs it with their own wallet and broadcasts it on-chain. The server **never sends the transaction and never holds private keys**. Tokens created through this endpoint route to the Robinhood `TrenchManager` (`0x77dC6f6361b7b99456FC3761ce5b7ddA80d83f9d`) and are priced in native ETH. ## Overview | | | | ------------------ | ----------------- | | **Chain** | Robinhood Mainnet | | **Base path** | `/papi/v1` | | **Authentication** | None | | **Pricing** | Native ETH only | Because the channel is public and unauthenticated, abuse is limited through the following mechanisms: | Mechanism | Behavior | | --------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Rate limiting** | The endpoint is rate limited. Exceeding the limit returns `429`; back off and retry (see [Error handling](#error-handling)). Contact the team if you need a higher quota. | | **Minimum dev buy** | `dev_buy_eth` must be **≥ 0.001 ETH**. Anything below the threshold returns `400`. | | **Request body limit** | Oversized bodies return `413`. | | **Native ETH pricing only** | ERC20-denominated quoting is not accepted (passing a non-zero `vault` is rejected). | ## Endpoint ``` POST /papi/v1/token/create?chain=robinhood Content-Type: application/json ``` The `chain` query parameter selects the target chain. For the Robinhood deployment, pass `robinhood`. Any unsupported value returns `400`. ### Request body | Field | Type | Required | Description | | ------------- | ------ | -------- | ------------------------------------------------------------------------------------------------------------------- | | `name` | string | Yes | Token name | | `symbol` | string | Yes | Token symbol | | `meta_uri` | string | Yes | Metadata URI. **The caller uploads to IPFS and passes the URI**; this channel does not perform server-side uploads. | | `dev_buy_eth` | string | Yes | Initial dev buy amount (ETH string, e.g. `"0.001"`). **Must be ≥ 0.001**. | | `creator` | string | Yes | Token creator address (an on-chain attribution parameter — see the security note below). | | `vault` | string | No | Leave empty or set to the zero address (native ETH pricing). **A non-zero address is rejected.** | {% hint style="warning" %} **About `creator`:** this field is an **on-chain attribution parameter; the server does not verify ownership**. The real on-chain actor is **the address that signs and broadcasts the transaction**. Front-ends should lock `creator` to the currently connected wallet address. Do not use `creator` to label an account as a "verified creator" in your UI. {% endhint %} ### Metadata format (the JSON that `meta_uri` points to) This channel does not upload metadata for you. The caller must upload the JSON below to IPFS and pass the resulting URI (e.g. `ipfs://`) as `meta_uri`. JSON schema: | Field | Type | Required | Description | | ---------- | ------ | -------- | ---------------------------------------------------------- | | `name` | string | Yes | Token name (matches the request body `name`) | | `symbol` | string | Yes | Token symbol (matches the request body `symbol`) | | `image` | string | Yes | Token logo image URI (e.g. `ipfs://` or an https URL) | | `website` | string | No | Website link | | `twitter` | string | No | Twitter/X link | | `telegram` | string | No | Telegram link | {% hint style="info" %} Field names are all lowercase. Omit optional keys entirely when they have no value. Keep this format so the platform's display layer parses it correctly. {% endhint %} Example metadata JSON: ```json { "name": "My Token", "symbol": "MYT", "image": "ipfs://bafybeigdyr...imageCID", "website": "https://mytoken.xyz", "twitter": "https://x.com/mytoken", "telegram": "https://t.me/mytoken" } ``` Upload this JSON to IPFS to obtain `ipfs://`, which becomes your `meta_uri`. ### Example request ```bash # is the API domain provided by the platform — contact the team to obtain it curl -X POST 'https:///papi/v1/token/create?chain=robinhood' \ -H 'Content-Type: application/json' \ -d '{ "name": "My Token", "symbol": "MYT", "meta_uri": "ipfs://bafy...", "dev_buy_eth": "0.001", "creator": "0x03dc87ff963a2133e8ec2c60d810639089dc8af8" }' ``` ## Response All responses use a common envelope: `{ "code": 0, "msg": "ok", "data": { ... } }`. `code = 0` means success. The `data` object fields (**note: field names are PascalCase, e.g. `To` / `Data` — this is intentional, parse accordingly**): | Field | Type | Description | | --------------------------- | ------ | ------------------------------------------------------------- | | `To` | string | Transaction target contract address (TrenchManager) | | `Data` | string | Transaction calldata (`0x…`) | | `Value` | string | Transaction `value` (wei string; includes the dev buy amount) | | `EstimatedTokenOut` | string | Estimated tokens received from the dev's first buy | | `PredictedToken` | string | Predicted address of the new token contract | | `NeedApprove` | bool | Always `false` for this endpoint (creation needs no approval) | | `ApproveTo` / `ApproveData` | string | Empty for the token-creation flow | ### How to sign and send the returned values The response provides only the **core transaction payload** (`To` / `Data` / `Value`). A complete transaction also needs `gas` / `nonce` / `from` / `chainId` — these are **supplied by the caller or wallet**; the server does not return them. * **Browser wallet** (MetaMask, ethers `signer.sendTransaction`): pass `{ to: To, data: Data, value: Value }` straight to the wallet. Gas, nonce, and chainId are filled in automatically; the user signs and it broadcasts. * **Server-side signing** (constructing a raw tx with a private key): do the following yourself: * estimate gas with `eth_estimateGas` (or use a sufficiently large gasLimit); * fetch the `from` address nonce with `eth_getTransactionCount`; * set `chainId` for the target chain; * sign with the signer's private key and broadcast with `eth_sendRawTransaction`. {% hint style="info" %} `Value` already includes the dev buy amount (native ETH paid via `msg.value`) — do not add it again. `NeedApprove` is `false`; token creation requires no prior approval. {% endhint %} ### Successful response example ```json { "code": 0, "msg": "ok", "data": { "To": "0x77dC6f6361b7b99456FC3761ce5b7ddA80d83f9d", "Data": "0x…", "Value": "5000000000000000", "EstimatedTokenOut": "…", "PredictedToken": "0x…cccc", "NeedApprove": false } } ``` ## Error codes | HTTP | code | Scenario | | ---- | ----------- | -------------------------------------------------------------------------------------------------------------------------------------------------------- | | 400 | 4000 | Missing/invalid parameter, invalid `creator` address, `dev_buy_eth` below the minimum, unsupported `chain` value, or a non-ETH-priced `vault` was passed | | 400 | 4030 / 4031 | Token has entered the migrating / migrated state (business rule) | | 429 | 4290 | Rate limit triggered | | 413 | 4130 | Request body too large | | 500 | 5001 | On-chain read failed (retryable) | {% hint style="info" %} Error messages (`msg`) are fixed strings and contain no dynamic detail (they do not echo your input parameters). {% endhint %} ### Request tracing Every response carries an `X-Request-Id` header (the trace ID for that request). **Include this ID when reporting an issue** so the team can locate the corresponding logs precisely. ### Error handling * **429 (rate limit)** — retry with **exponential backoff** (first wait ≥ 1s, doubling each time). If 429s persist, reduce concurrency or contact the team. * **500** — a transient on-chain read failure; retry the request as-is. * **400** — the request itself is invalid; retrying will not help. Fix the input per `msg`. ## Integration notes 1. **Bring your own metadata** — assemble the JSON per [Metadata format](#metadata-format-the-json-that-meta_uri-points-to) (name/symbol/image plus optional socials), upload to IPFS, and pass the resulting `meta_uri` when calling this endpoint. 2. **Rate limiting is the primary protection** — this channel has no API key, so pace your calls sensibly. On `429`, back off and retry per [Error handling](#error-handling); contact the team ahead of time if you need higher throughput. 3. **Minimum dev buy** — a `dev_buy_eth` below the threshold is rejected (currently 0.001 ETH; the threshold may change). 4. **Native ETH pricing only** — ERC20-denominated token creation is not supported. 5. **Fill in the signing envelope yourself** — the response returns only the core calldata fields; gas/nonce/chainId are supplied by the wallet or caller (see [How to sign and send the returned values](#how-to-sign-and-send-the-returned-values)). ## Versioning and changes * This endpoint is **v1** (the `/papi/v1` in the path). Fields follow an **additive-only** policy; breaking changes ship under a new version number (`/papi/v2`), with the old version retained during a transition period. * For the API domain, change notifications, and higher-throughput quota requests, contact your platform representative. ### Changelog | Date | Change | | ---------- | --------------------------------------------------- | | 2026-07-12 | v1 initial release: create token (returns calldata) | --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://trench-today.gitbook.io/trench-today/for-developers/public-api.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.