# Geomi Documentation (Complete)

This is the complete Geomi documentation, containing all content from the documentation site.

---

# About Geomi
URL: https://geomi.dev/docs/

# About Geomi

Geomi is an all-in-one platform for developers to create, test, and launch dApps on the [Aptos blockchain](https://aptosfoundation.org/). Whether you’re building your first project or scaling production apps, Geomi provides the tools you need to move fast and focus on your product.

With Geomi, you can:

- Leverage [No-Code Indexing](/docs/no-code-indexing) to build custom data indexers and APIs without writing code or running infrastructure.
- Sponsor user transactions and manage gas costs with [Gas Stations](/docs/gas-stations).
- Instantly generate API keys for access to Aptos Full Node, Indexer, and Analytics APIs.
- Onboard users with intuitive, secure Keyless accounts and on-chain identity.

Geomi is designed to streamline your development workflow, eliminate infrastructure headaches, and help you deliver great blockchain experiences—fast.

**Ready to get started?** [See our Getting Started guide](/docs/start).

---

# Definitions
URL: https://geomi.dev/docs/admin/billing

## Definitions

- **User**: Someone with a Geomi account (e.g. `jim@stablelabs.com`).
- **Organization:** This is what actually owns projects and resources. Organizations have many members and admins but just one owner. Payment methods are attached to organizations, not users. For example `stable-labs`.
- **Monthly Credit**: A credit in terms of US dollars that Aptos Labs grants the organization each month. It is use it or lose it, the credit does not roll over to the next month.
- **System Limits**: These are caps that we set on the amount of resources that an organization is allowed to use. These exist to protect our infra from unexpectedly high usage. They are defined in terms of the service, e.g. CUs per 5 mins.
- **Budgets**: We allow organization admins to set a daily and/or monthly budget for their spending. Budgets are in dollar terms, not per-resource terms. Since they are enforced asynchronously, it is possible to slightly exceed your budget. You can set these on the _Usage_ tab in the side nav.

## Billing

Usage of our services accrues a cost in dollars (USD) according to the following price schedule:

Except for the per-processor limits, these limits apply to the whole organization. For example, all API usage shares the same Compute Units / 5 mins limit.

## Cost Dimensions

---

# Resource Management
URL: https://geomi.dev/docs/admin/resource-management

# Resource Management

Learn about resource management with this video:

[Video embedded]

## Resource Hierarchy

Resources in Geomi are organized in a hierarchical structure:

```
Organization
└── Projects
    └── Resources (APIs, Indexers, etc.)
```

### Resource Organization

Resources are managed within projects, which are owned by organizations. This structure provides:

- Clear resource ownership and boundaries
- Isolated environments for different applications
- Shared infrastructure and access controls
- Centralized billing and usage management

### Resource Access Control

Access to resources is controlled through organization roles:

- **Owners**: Have full control over all resources, including:
  - Creating and managing projects
  - Setting resource usage limits
  - Managing resource access
  - Configuring billing settings

- **Admins**: Can manage project resources, including:
  - Creating and configuring resources
  - Managing resource settings
  - Monitoring resource usage
  - Cannot modify billing or organization settings

- **Members**: Can use resources, including:
  - Accessing assigned resources
  - Viewing resource status
  - Using resource features
  - Cannot modify resource settings

## Resource Management Features

### Resource Isolation

Projects provide isolated environments for resources:
- Separate resource configurations
- Independent scaling and monitoring
- Isolated access controls
- Clear resource boundaries

### Resource Sharing

Resources can be shared across projects while maintaining:
- Usage tracking per project
- Access control boundaries
- Resource quotas
- Billing separation

## Member Management

Effective member management is essential for controlling resource access and maintaining security.

### Managing Organization Members

1. Go to your organization settings
2. Navigate to the "Users" tab
3. Click "Add User" to invite new members
4. Enter the email address and select the role:
   - **Admin**: Can manage projects and resources
   - **Member**: Can view and use resources
5. The invited member will receive an email to accept the invitation

### Changing Member Roles

Organization owners can:
- Change member roles between Admin and Member
- Remove members from the organization
- Transfer ownership to another member
- Cannot change their own role (must transfer ownership first)

---

# API Keys
URL: https://geomi.dev/docs/api-keys

## API Keys

API keys are how your resource identifies itself to us for authentication and rate limiting purposes. If you do not use an API key, your client will be considered "anonymous" and subject to significantly lower rate limits. You can learn how to attach an API key to your requests by using the snippets on the detail page of any resource.

As a general rule, you should only have one API key at a time per resource. Geomi lets you create multiple keys for a single resource purely to enable key rotation in case a key is leaked.

## Client Usage

When creating a new API key you will be prompted to decide whether it is intended for client usage or not. Client usage implies any context where the API key is exposed to the public, e.g. a dapp, a mobile app, or a browser extension. If you will only use the API key in a private, backend context, you do not need to worry about this.

If you select "Client Usage" you will be prompted to provide a set of approved URLs and/or extension IDs. We will confirm that the [Origin](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Origin) of the request matches one of the approved URLs or extension IDs.

When using a client key you can configure per-IP rate limit rules. These rules let you control how many requests each individual IP address can make, helping prevent abuse from any single user of your application. You can create up to 6 rules per key, with each rule targeting different scopes (all requests, specific upstreams, specific operations, etc.).

Learn more about [per-IP rate limit rules](/docs/api-keys/frontend-keys) and [billing and system limits](/docs/admin/billing).

## Key Types

To help you manage your keys correctly, you'll notice that keys intended for client usage have a different format than keys intended for backend usage:

- <b>Server:</b> Used from a private backend. Keep these secret. Example: `aptoslabs_aXjFX8fDdZv_AXMynDZvp711WTBpSBmqLyj12RV9RFA6B`
- <b>Client:</b> Used from a public frontend. We perform additional checks and analytics to ensure
  the use of these IDs is authentic. Example: `AG-FL4PYMZ1YX1LGAJCWP2R1ACYTYRCBY1GB`

## Anonymous Requests

Certain Geomi services (e.g. the node and indexer APIs) allow unauthenticated requests, also known as anonymous requests. When no key is provided, ratelimiting is applied on a per-IP per-origin basis. Anonymous limits are significantly lower than authenticated limits.

---

# Frontend Keys
URL: https://geomi.dev/docs/api-keys/frontend-keys

# Frontend Keys

When using a frontend (client) API key, you can configure per-IP rate limit rules and per-IP stream limits to control how each individual IP address can use your application. This helps prevent abuse from any single user.

## Per-IP Rate Limit Rules

Per-IP limit rules let you define granular rate limits that apply to each IP address using your frontend key. Each rule specifies:

- **Scope**: What requests the rule applies to (per upstream, specific upstream, etc.)
- **Limit Unit**: How the limit is measured (compute units, request count)
- **Window**: The time window for the limit (e.g. 5 minutes)
- **Limit**: The maximum allowed in the time window (use 0 to block)

Rules are evaluated independently - a request must satisfy all applicable rules to be allowed.

## Scope Types

### Default per upstream

Creates a separate rate limit counter for each upstream service type. This means an IP gets the specified limit for **each** service they use.

```
Scope: Default per upstream
Limit: 50,000 Compute Units
Window: 5 minutes
```

With this rule, a single IP could use:

- 50,000 CUs against the node API
- 50,000 CUs against the indexer API
- etc.

In other words, each upstream maintains its own counter.

### Specific upstream

Applies a limit only to a specific upstream service (e.g., node API, indexer API). Other upstreams are unaffected by this rule. You can use this to grant a higher limit to particular upstream, or alternatively you could set the value to zero to block a particular upstream.

In most cases you should use this in conjunction with a "default per upstream" rule. You can find the node operation IDs by looking for `operationId` in the [OpenAPI spec](https://api.mainnet.aptoslabs.com/v1/spec.json).

### Default per node operation

Similar to "Default per upstream" but for node API operations. Each operation (like `get_account`, `get_transactions`) gets its own counter.

### Specific node operation

Set a different limit for a specific node API operation.

### Default per GraphQL table

Creates separate counters for each GraphQL table accessed through GraphQL APIs. These include the core indexer API as well as no code indexing APIs. See all GraphQL tables (e.g. `account_transactions`) for the core indexer API [here](https://cloud.hasura.io/public/graphiql?endpoint=https://api.mainnet.aptoslabs.com/v1/graphql).

### Specific GraphQL table

Set a different limit for a specific GraphQL table.

## Default vs specific scopes

**Default scopes** (like "Default per Upstream") create a separate counter for each item in that category. If you set a limit of 50,000 CUs with "Default per Upstream", each upstream type gets its own 50,000 CU allowance.

**Specific scopes** (like "Upstream: NodeApi") apply only to that one item. You can combine a default scope with specific overrides:

```
Rule 1: Default per Upstream - 50,000 CUs / 5min
Rule 2: Upstream: NodeApi - 20,000 CUs / 5min
```

In this case:

- Node API is limited to 20,000 CUs (the specific rule overrides the default)
- All other upstreams get 50,000 CUs each

## Example configurations

### Simple protection

One rule giving each upstream its own limit:

| Scope                | Limit   | Unit          | Window |
| -------------------- | ------- | ------------- | ------ |
| Default per Upstream | 100,000 | Compute Units | 5 min  |

### Service-Specific Limits

Different limits for different services. Note: you should always include a default rule.

| Scope                | Limit   | Unit          | Window |
| -------------------- | ------- | ------------- | ------ |
| Default per Upstream | 50,000  | Compute Units | 5 min  |
| Upstream: NodeApi    | 100,000 | Compute Units | 5 min  |
| Upstream: IndexerApi | 30,000  | Compute Units | 5 min  |

### Protect expensive tables

Limit specific expensive GraphQL tables:

| Scope                           | Limit   | Unit          | Window |
| ------------------------------- | ------- | ------------- | ------ |
| Default per Upstream            | 100,000 | Compute Units | 5 min  |
| Default per GraphQL Table       | 50,000  | Compute Units | 5 min  |
| GraphQL table: token_activities | 5,000   | Compute Units | 5 min  |

This allows generous overall usage but restricts the expensive `token_activities` table.

### Block all traffic except for specific tables

To express "block all upstreams except for specific indexer API tables", you need multiple rules that work together:

| Scope                           | Limit     | Unit          | Window |
| ------------------------------- | --------- | ------------- | ------ |
| Default per Upstream            | 0         | Request Count | 5 min  |
| Upstream: IndexerApi            | 1,000,000 | Request Count | 5 min  |
| Default per GraphQL Table       | 0         | Request Count | 5 min  |
| GraphQL table: coin_activities  | 100       | Request Count | 5 min  |
| GraphQL table: token_activities | 100       | Request Count | 5 min  |

How this works:

1. **Default per Upstream = 0**: Blocks all upstreams by default.
2. **Upstream: IndexerApi = high value**: Allows the indexer API (overrides the default).
3. **Default per GraphQL Table = 0**: Blocks all GraphQL tables by default.
4. **Specific GraphQL tables = intended limit**: Allows only the tables you specify with their intended rate limits.

This pattern lets you create allowlist-style rules where everything is blocked except what you explicitly permit.

**Note**: This kind of overriding behavior only works for rules with the same "key", where key is unit (e.g. request count) + window (e.g. 5 mins).

## Per-IP Concurrent Stream Limit

In addition to rate limits, you can configure a per-IP concurrent stream limit. This controls how many long-running streaming connections (such as WebSocket or gRPC streams) each IP address can have open simultaneously.

### Why use stream limits?

Streaming connections are long-lived and consume server resources for their entire duration. Without limits, a single malicious or misbehaving client could:

- Open hundreds of connections from one IP, exhausting your organization's stream quota
- Prevent legitimate users from establishing new connections
- Cause unexpected costs

### How it works

When you set a per-IP stream limit (e.g., 2), each IP address using your frontend key can only have that many concurrent streams open at once. If they try to open more, the connection will be rejected with an HTTP 429 (Too Many Requests) error. Setting the limit to 0 will block all streaming connections for frontend keys.

### Example

If you set:

- **Per-IP stream limit**: 2
- **Organization stream limit**: 100

Then:

- Each individual IP can have at most 2 concurrent streams
- Your organization can have up to 100 total streams across all IPs
- If one IP opens 2 streams, they cannot open more until one closes
- Other IPs are unaffected and can still open their own streams (up to 2 each)

---

# API Reference
URL: https://geomi.dev/docs/api-reference

# API Reference

This page provides a comprehensive reference for all Geomi APIs. Choose an API below to view endpoints, authentication, and examples.

## Overview

Geomi provides access to multiple Aptos blockchain APIs:

- **Node API** - Direct blockchain access (REST)
- **Indexer API** - Advanced queries (GraphQL)
- **Transaction Stream** - Real-time data (GRPC)

## Authentication

While anonymous API access is available with rate limits, we strongly recommend using a Geomi API key for significantly higher limits and usage tracking. [Learn how to create one](/docs/api-keys) or get started now by [creating a new API key in Geomi](/manage/create-api-resource).

```bash
curl "https://api.mainnet.aptoslabs.com/v1" \
  -H "Authorization: Bearer YOUR_API_KEY_HERE"
```

## Rate Limits & Billing

All APIs use a Compute Unit (CU) based billing system. For detailed pricing and limits, see the [Billing Documentation](/docs/admin/billing).

### About Compute Units (CUs)

- CUs measure the relative infrastructure cost of a request.
- More complex or longer‑running requests consume more CUs.
- For current formulas, limits, and prices, see [Billing](/docs/admin/billing).

---

---

## SDKs

Aptos provides official SDKs for multiple languages. For full documentation, installation guides, and examples, see the [SDK documentation on aptos.dev](https://aptos.dev/build/sdks).

**Quick Start:**
- **TypeScript:** `npm install @aptos-labs/ts-sdk` - [Docs](https://aptos.dev/build/sdks/ts-sdk)
- **Python:** `pip install aptos-sdk` - [Docs](https://aptos.dev/build/sdks/python-sdk)
- **Rust:** [Installation Guide](https://aptos.dev/build/sdks/rust-sdk)
- **Go:** [Installation Guide](https://aptos.dev/build/sdks/go-sdk)

## Next Steps

- [Create an API Key](/docs/api-keys)
- [View Pricing & Limits](/docs/admin/billing)
- [Getting Started Guide](/docs/start)

---

# 📘 Aptos MCP Documentation
URL: https://geomi.dev/docs/aptos-mcp

# 📘 Aptos MCP Documentation

## Overview

The Aptos Model Context Protocol (MCP) is a server designed to be used with AI tools like Cursor, Claude Code, and others that support the Model Context Protocol. It provides you with dozens of tools and guides to help AI and developers build applications on the Aptos blockchain. It automates interactions with the Aptos Geomi platform while providing current best practices for Aptos development.

## What This MCP Server Can Do

### 🚀 **Geomi Platform Automation**
- **22 specialized tools** that automate Geomi platform interactions
- **Instant setup** vs. 5-15 minutes of manual web interface navigation
- **Complete gas station automation** with sponsorship rules (eliminates weeks of custom infrastructure development)
- **Enterprise project management** through programmatic API calls

### 🧠 **AI Agent Development Guidance**
- **15 comprehensive development guides** ensures your AI agent is using current Aptos best practices and wallet adapters
- **MCP-first workflow enforcement** prevents outdated pattern usage
- **Current Move development patterns** for code that compiles on first try
- **Cutting-edge feature support** for Geomi's APIs, sponsored transactions and no-code indexers

## Aptos MCP + Geomi Integration

The Aptos MCP enables AI agents to programmatically manage key components of the **Geomi** platform:

- **Organizations** - Create and manage organizational structures
- **Projects** - Set up development projects within organizations  
- **API Keys** - Create API keys for higher rate limits and usage tracking
- **Gas Stations** - Set up sponsored transaction infrastructure

This eliminates manual web interface navigation, letting you automate Geomi platform management.

## Getting Started

Follow [this guide](https://aptos.dev/build/ai/aptos-mcp) on how to integrate the Aptos MCP into your development environment.

### Prerequisites
- [Node.js and npm](https://nodejs.org/en)
- Geomi Bot API Key

### Generate a Geomi Bot API Key

To enable Geomi platform automation, follow these instructions:

1. Go to [https://geomi.dev/manage/bot-keys](https://geomi.dev/manage/bot-keys)
2. Click on your name in the bottom left corner
3. Click on "Bot Keys"
4. Click on the "Create Bot Key" button
5. Copy the Bot Key and paste it into the MCP configuration file as an env arg: `APTOS_BOT_KEY=<your-bot-key>`

### Create New API Resource

The MCP can automatically create API resources and applications for you. You can either:

- **Use the MCP to create everything programmatically** (recommended)
- **Manually create resources** in your [Geomi dashboard](/manage/create-api-resource) if you prefer

The MCP will guide you through the automated setup process when you use the prompt examples below.

## 💡 Prompt Examples

Here are examples of how to prompt an agent to use the supported tools:

### Creating API Resources
```
Create a new API key called "my-api-key" in my application called "MyDashboard" in the "growth-tools" project under the "MarketingOps" organization
```

### Setting Up Gas Station (Sponsored Transactions)
```
In Geomi, create a gas station application called "MyGasStation" in my "Web3App" project with sponsorship rules for user onboarding functions
```

### Managing Organizations
```
Create a new organization called "MyCompany" and set up a project called "Web3App" with an application called "MainApp" in Geomi
```

### Getting Development Guidance
```
Help me build a complete Aptos dApp with sponsored transactions and wallet integration
```

These prompts will generate the necessary resources and provide example code for integration.

## Available APIs Through Geomi

The Aptos MCP helps you manage API keys for all Geomi APIs:

### Core APIs
- **Node API (REST)** - Direct blockchain access
  - Endpoint: `https://api.mainnet.aptoslabs.com/v1`
  - [Documentation](https://aptos.dev/build/apis/fullnode-rest-api)

- **Indexer API (GraphQL)** - Advanced blockchain queries
  - Endpoint: `https://api.mainnet.aptoslabs.com/v1/graphql`
  - [Documentation](https://aptos.dev/build/indexer)

- **Transaction Stream (GRPC)** - Real-time transaction data
  - Endpoint: `grpc.mainnet.aptoslabs.com:443`
  - [Documentation](https://aptos.dev/build/indexer/txn-stream)

### Complete API Reference

For comprehensive API documentation including endpoints, authentication, rate limits, and examples:

[View API Reference](/docs/api-reference)

---

# Untitled
URL: https://geomi.dev/docs/faq

### Why am I receiving 429 errors?

There are a number of possible reasons you might be seeing this error. If you haven't already, check the response body for more details, we include a detailed plain text message explaining the reason for the 429.

If you see a message like `Per anonymous IP rate limit exceeded`, it implies that you are not including an API key with your requests. Make sure to include it as a header: `Authorization: Bearer <your_api_key>`. See the snippets on the API key page for more examples of how to set the API key depending on your client.

If you see something like `Per application per IP rate limit exceeded. Limit: x compute units per 300 seconds window`, it means you are using a client side API key, but your users are hitting the per IP limit you set for that key. You can increase this limit by editing the API key:

This limit exists to help prevent abuse by a single IP address, but you can set the value to whatever you want.

### What are the anonymous limits?

Anonymous limits apply to requests that do not include an API key. Some limits are applied per IP address, while others are applied per IP + origin (to ensure no single site uses up the whole limit):

If you want to access higher limits, please create an account on [Geomi](https://geomi.dev/) to generate an API key. You can further increase your free limits by attaching a credit card (you won't be charged unless you exceed your limits, and can set budgets to help prevent that).

---

# Gas Stations
URL: https://geomi.dev/docs/gas-stations

# Gas Stations

Gas stations are a powerful resource that allows you to subsidize transaction fees for your users. This means your users can interact with your dApp without needing to hold APT tokens for gas fees, making the user experience much smoother.

## How It Works

A gas station acts as a fee payer for transactions on the Aptos blockchain. When properly configured:

1. Your users submit transactions using your dApp
2. The gas station automatically pays the gas fees
3. Your users don't need to hold APT tokens
4. You maintain control over which transactions can be subsidized

## Creating a Gas Station

To create a gas station:

1. Navigate to your project page
2. Add a "Gas Station" resource
3. Provide a name and select a network
4. Configure the initial contract rules

## Integration

This guide explains how to use the Geomi Gas Station in a Typescript based dapp.

Install the relevant packages:
```
pnpm add \
  @aptos-labs/ts-sdk@^5.0.0 \
  @aptos-labs/gas-station-client@^2.0.3 \
  @aptos-labs/wallet-adapter-react@^7.0.0
```

Build a gas station client and either use it directly, or configure the `Aptos` client to use it to submit transactions:

```typescript

const network = Network.MAINNET;
const gasStationClient = new GasStationClient({
  network,
  apiKey: "aptoslabs_34edbqbxyPrS_6fu9i83mYmjid4MVs3Z3XmCeATQ8tkSda",
});

// Set up Aptos client with gas station
const transactionSubmitter = new GasStationTransactionSubmitter(gasStationClient);

const config = new AptosConfig({
  network,
  pluginSettings: {
    TRANSACTION_SUBMITTER: transactionSubmitter,
  },
});
const aptos = new Aptos(config);
```

If you're using the wallet adapter, you can configure it to use the gas station client too:

```tsx

```

From this point on, any transaction you submit with the TS SDK client or via the wallet adapter (e.g. with `signAndSubmitTransaction` from `useWallet`) will be submitted via the gas station.

If you have configured a reCAPTCHA check, you can provide the token as part of submitting the transaction like this:

```typescript

const { signAndSubmitTransaction } = useWallet();

// Make the user do a reCAPTCHA check.
const recaptchaToken = await getRecaptchaToken();

// Build and submit the transaction with the reCAPTCHA token. This will sign locally
// and then submit to the gas station.
const response = await signAndSubmitTransaction({
  data: {
    function: "0x1::coin::transfer",
    typeArguments: [APTOS_COIN],
    functionArguments: ["0x9", 100_000_000],
  },
  withFeePayer: true,
  pluginParams: { recaptchaToken },
});
```

## Contract Rules

Contract rules define which transactions can be subsidized by your gas station. For each contract, you can:

- Specify which functions can be called
- Set spending limits per function
- Enable reCAPTCHA protection
- Configure rate limits

## Billing

Gas stations are billed based on the actual gas costs of the transactions they subsidize. You can:

- Monitor usage in real-time
- Set up alerts for high usage
- View detailed billing reports
- Configure spending limits

Learn more about billing and costs [here](/docs/admin/billing#cost-dimensions) (see "Gas" in the Cost Dimensions section).

## Security Features

Gas stations include several security features to protect your resources:

1. **Function-level Control**: Only allow specific functions to be called
2. **Spending Limits**: Set maximum gas costs per function
3. **Rate Limiting**: Prevent abuse through request throttling
4. **reCAPTCHA**: Optional protection against automated attacks
5. **API Key Authentication**: Secure access to your gas station

## Limitations

- Gas stations can only subsidize transactions on the specified network
- Each function call must be explicitly allowed in the contract rules
- There are rate limits and spending limits to prevent abuse
- Some complex transactions may not be supported

---

# Shelby USD Sponsorship
URL: https://geomi.dev/docs/gas-stations/shelby

# Shelby USD Sponsorship

[Shelby](https://shelby.xyz) is a storage protocol that uses Aptos as its coordination layer. Certain Shelby operations, such as registering blobs, require payment in ShelbyUSD (in addition to the usual gas costs in APT). Normally, your users would need to hold and spend ShelbyUSD to perform these operations.

With ShelbyUSD sponsorship enabled, your gas station can cover these ShelbyUSD costs on behalf of your users, providing a smoother user experience where users don't need to hold any assets at all.

## How It Works

1. **Standard Gas Sponsorship**: Your gas station pays APT gas fees for transactions.
2. **ShelbyUSD Sponsorship**: Your gas station additionally covers ShelbyUSD storage costs.

When you enable ShelbyUSD sponsorship:

- The gas station fee payer account will be funded with ShelbyUSD in addition to APT.
- Your users call Shelby functions with the `_with_sponsor` suffix (the Shelby SDK handles this automatically).
- The gas station signs as both a fee payer (for APT gas) and a secondary signer (for ShelbyUSD sponsorship).

## How to create a gas station with ShelbyUSD sponsorship

The option to enable ShelbyUSD sponsorship only appears when you're configuring a gas station for the Shelby contract on shelbynet or testnet. When creating a gas station, input the contract address.

{/* TODO: Pull these dynamically from the gas station's /admin/config/shelby endpoint. */}

**Shelbynet**

| Address Type                  | Address                                                              |
| ----------------------------- | -------------------------------------------------------------------- |
| Contract address              | `0x85fdb9a176ab8ef1d9d9c1b60d60b3924f0800ac1de1cc2085fb0b8bb4988e6a` |
| ShelbyUSD FA metadata address | `0x1b18363a9f1fe5e6ebf247daba5cc1c18052bb232efdc4c50f556053922d98e1` |

**Testnet**

| Address Type                  | Address                                                              |
| ----------------------------- | -------------------------------------------------------------------- |
| Contract address              | `0x85fdb9a176ab8ef1d9d9c1b60d60b3924f0800ac1de1cc2085fb0b8bb4988e6a` |
| ShelbyUSD FA metadata address | `0x1b18363a9f1fe5e6ebf247daba5cc1c18052bb232efdc4c50f556053922d98e1` |

Once you have created the gas station, record the fee payer address and API key.

## Client Integration

### Using the Shelby SDK (Recommended)

The [`@shelby-protocol/sdk`](https://www.npmjs.com/package/@shelby-protocol/sdk) has built-in support for ShelbyUSD sponsorship. When you pass `usdSponsor` to the SDK, it automatically:

1. Uses the `_with_sponsor` variants of entry functions (e.g., `register_blob_with_sponsor` instead of `register_blob`).
2. Includes your gas station's fee payer as a secondary signer in the transaction.
3. Routes the transaction through the gas station for co-signing via the transaction submitter plugin.

Install the required packages:

```bash
pnpm add @shelby-protocol/sdk @aptos-labs/gas-station-client @aptos-labs/ts-sdk
```

Set up the gas station client and Shelby blob client:

```typescript

// 1. Create a gas station client with your API key.
const gasStationClient = new GasStationClient({
  network: Network.SHELBYNET,
  apiKey: "YOUR_GAS_STATION_API_KEY",
});

// 2. Wrap it in a transaction submitter plugin.
const transactionSubmitter = new GasStationTransactionSubmitter(gasStationClient);

// 3. Create a ShelbyBlobClient with ShelbyUSD sponsorship enabled.
const blobClient = new ShelbyBlobClient(
  {
    network: Network.SHELBYNET,
    aptos: {
      pluginSettings: {
        TRANSACTION_SUBMITTER: transactionSubmitter,
      },
    },
  },
  {
    // The feePayerAddress is your gas station's fee payer, which you can find on the
    // gas station overview page.
    usdSponsor: {
      feePayerAddress: AccountAddress.from("0x<your-fee-payer-address>"),
    },
  },
);
```

From here, all blob operations automatically use the sponsored variants:

```typescript
// The SDK calls register_blob_with_sponsor under the hood and routes
// the transaction through the gas station for co-signing.
await blobClient.upload({
  blobData: myData,
  signer: userAccount,
  blobName: "example.txt",
  expirationMicros: Date.now() * 1000 + 86400_000_000,
});
```

### Details

When ShelbyUSD sponsorship is enabled, additional functions become available that end with `_with_sponsor`. These are special variants that allow the gas station to authorize ShelbyUSD payments on behalf of the user.

For example:

- `register_blob` → `register_blob_with_sponsor`
- `register_multiple_blobs` → `register_multiple_blobs_with_sponsor`
- `increase_expiration_time` → `increase_expiration_time_with_sponsor`

You can use both types of sponsorship simultaneously so your users don't need to hold any tokens at all.

|                      | **APT Sponsorship**             | **ShelbyUSD Sponsorship**         |
| -------------------- | ------------------------------- | --------------------------------- |
| What it pays         | Gas fees (APT)                  | Storage fees (ShelbyUSD)          |
| How to enable        | `build: { withFeePayer: true }` | `usdSponsor: { feePayerAddress }` |
| Entry functions used | Standard (`register_blob`)      | `_with_sponsor` variants          |

When both are enabled, the gas station signs as both the fee payer (for APT gas) and a secondary signer (for costs in ShelbyUSD).

---

# No Code Indexing
URL: https://geomi.dev/docs/no-code-indexing

# No Code Indexing

## Intro

Most novel products on Aptos require custom indexing. Unfortunately, custom indexing is hard for two key reasons:

1. Devs must write code to describe their indexing logic.
1. Devs must manage infrastructure to run an indexer.

The Geomi No Code Indexing platform solves both of these problems by eliminating the need to write code or run infrastructure yourself.

Learn how to use No Code Indexing in 116 seconds with this video:

[Video embedded]

## Demonstration

Learn how to use Geomi No Code Indexing with this end-to-end demo, using the Petra Web Hong Bao experience as an example:

[Video embedded]

Resources referred to in the demo:

- [Petra Web Hong Bao](https://aptosconnect.app/dashboard/main-account/apps/?widget=hongbao)
- [Hong Bao Move code](https://github.com/aptos-labs/hong-bao/tree/main/move)
- [Getting started with Hasura v2](https://hasura.io/docs/2.0/getting-started/how-it-works/index/)
- [GraphQL Typescript codegen package](https://the-guild.dev/graphql/codegen/plugins/typescript/typescript)
- [GraphQL codegen example](https://github.com/aptos-labs/aptos-ts-sdk/blob/main/src/types/codegen.yaml)

## Behavior

### Merging events

To write multiple events into the same row a primary key must be specified. We merge on the specified PK:

When you enable public API access for your processor, anyone can query your processor's API using their own API key. It has the following properties:

- **Billing:** The caller gets billed for API usage, not you.
- **Access:** Anyone with any valid API key can query this endpoint. The key does not have to be for a processor, a regular API key works too.
- **Read-only:** This endpoint is read-only, callers cannot write data or change your Hasura metadata.

The public URL follows the pattern:

```
https://api.{network}.aptoslabs.com/nocode/v1/public/{instance_id}/v1/graphql
```

To enable or disable public API access:

1. Navigate to the page for your processor.
2. Click the three dots menu in the top right.
3. Select "Enable Public API" or "Disable Public API".

## Considerations

### Complex Types

- We support `Vec<T>`. At the moment `T` must be a primitive type (u8 → u256, address, String). It will become `ARRAY` in the DB.
- We support fields with generics, but don’t support indexing events that themselves have a generic type:

```rust
// This is supported.
#[event]
struct MyEvent has drop, store {
   field1: MyStruct<u64>,
}

struct MyStruct<T> has drop,store {
    my_value: T,
    other_value: u16,
}

// This is not supported.
#[event]
struct MyEvent<T> has drop, store {
   field1: T
}
```

---

# Getting Started
URL: https://geomi.dev/docs/start

# Getting Started

## Getting Started

To get started with the [services](/docs) offered as part of Geomi you must create an Geomi account [here](/). When you create an account, we will automatically create a personal organization for you. You can create more organizations [here](/manage/create-organization).

Learn more about how Geomi billing works [here](/docs/admin/billing).

## API Quick Start
While anonymous access to Aptos Labs APIs is permitted with a low rate limit, to get significantly higher rate limits and useful metrics to track your usage, you must create an Geomi account and attach an API key to all requests you make to Labs hosted APIs.

1. Create an account [here](/).
1. Create a new API key by clicking on the API Key card on the overview page.
1. Complete the form to create the new resource.
1. Use the example code snippets to learn how to use the API key.

Learn more about API keys [here](/docs/api-keys).

---