> ## Documentation Index
> Fetch the complete documentation index at: https://docs.tribridge.xyz/llms.txt
> Use this file to discover all available pages before exploring further.

> ## Agent Instructions
> Tribridge is a crypto payment gateway for Solana and Sui (TON is coming soon). API base URL is https://tribridge.onrender.com. Server-side calls authenticate with the x-api-key header using a tri_test_... key (fully simulated test mode, no real funds) or tri_live_... key (real mainnet payments) — never expose keys client-side. Merchant test mode is simulated, not testnet. Refunds are automatic only (underpaid/overpaid), there is no manual refund endpoint. Always verify webhook HMAC-SHA256 signatures from the X-Tribridge-Signature header before trusting payloads.

# API Keys

> One keypair for test and live mode, plus per-endpoint webhook signing secrets.

## One keypair, two modes

When you generate keys from your dashboard, Tribridge issues a single **keypair** containing both a **test** and a **live** key. Each key is shown exactly once at creation time — store it somewhere safe before closing the dialog.

<CardGroup cols={2}>
  <Card title="Test Key — tri_test_..." icon="flask-conical">
    Routes payments through test mode. No real funds move. Use this while building and validating your webhooks.
  </Card>

  <Card title="Live Key — tri_live_..." icon="zap">
    Activates real on-chain payments. Never expose it publicly, and only switch to it once your integration is verified in test mode.
  </Card>
</CardGroup>

A generated keypair looks like this (returned once, never retrievable again):

```json Example keypair response theme={null}
{
  "keypair_id": "f4c2...b91a",
  "test":  { "full_key": "tri_test_9f3a...", "is_test": true },
  "live":  { "full_key": "tri_live_2b7c...", "is_test": false }
}
```

Every server-side request carries the key in the `x-api-key` header:

```
x-api-key: tri_test_9f3a1c7e8b2d4f6a0c1e3b5d7f9a2c4e
```

## Webhook secrets

Separately from your API keys, every **webhook endpoint** you register receives its own signing secret. It is returned only once when the endpoint is created, and it is what lets you prove incoming webhooks genuinely came from Tribridge (see [Authentication](/authentication)). Treat it like a password.

```bash Create a webhook (returns secret once) theme={null}
curl -X POST https://tribridge.onrender.com/webhooks \
  -H "Authorization: Bearer <YOUR_JWT>" \
  -H "Content-Type: application/json" \
  -d '{ "url": "https://yoursite.com/tb-webhook", "is_test": true }'
```

Register **separate endpoints for test and live mode** — each gets its own secret.

## Rotating and revoking keys

<Steps>
  <Step title="Generate a fresh keypair">
    In the dashboard under **API Keys**, generate a new keypair. Both a new test and live key are issued together.
  </Step>

  <Step title="Update your server config">
    Swap the old keys for the new ones in your environment variables or secrets manager, then deploy.
  </Step>

  <Step title="Revoke the old keypair">
    Revoke the previous keypair from the dashboard. Requests using it immediately start returning `401`.
  </Step>
</Steps>

<Warning>
  The test and live keys are a pair: **revoking one revokes both**. Plan key rotation accordingly, and if a key is ever compromised, revoke it immediately and generate a fresh keypair.
</Warning>

## Security best practices

* Always load keys from environment variables — never hardcode or commit them.
* Never put API keys in frontend/mobile code; only your server should call Tribridge with them.
* Your webhook signing secret is shown once. Store it securely; you cannot retrieve it again.
* Use separate environment variables for test and live keys so you can't mix them up.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.