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

# Partner API Overview

> Manage a portfolio of child accounts, send and reconcile SMS, and receive signed webhooks — the API surface for ISV and platform partners.

The Partner API lets a platform or ISV manage many businesses under one integration. Your **parent** account creates and controls a fleet of **child** accounts — typically one child per business or location — and mints scoped API keys for each. From there, every standard v2 endpoint (send, contacts, lists, schedules) works per child, and a set of partner-only endpoints let you provision children, read messages and billing across the whole portfolio, and receive signed delivery webhooks.

<Note>
  The Partner API is additive: a child account is a normal Trackly SMS account. Everything in the rest of this reference works inside a child exactly as it does for a standalone customer. The pages below cover only the partner-specific surface.
</Note>

## Base URL & authentication

All endpoints are served under `https://api.tracklysms.com/api` and authenticate with an API key in the `X-Api-Key` header (a `Authorization: Bearer <key>` fallback is also accepted).

```
X-Api-Key: trk_your_api_key_here
```

Parent-level operations (creating children, issuing keys, cross-portfolio reads) use your **parent** key. Sends and other per-business operations use the **child** key you minted for that account.

## What's in Phase A

<CardGroup cols={2}>
  <Card title="Accounts & hierarchy" icon="sitemap" href="/api-reference/v2/accounts/overview">
    The parent → child model, external IDs, pooled billing, and API-key issuance.
  </Card>

  <Card title="Messages read & reconciliation" icon="magnifying-glass" href="/api-reference/v2/messages/list-messages">
    List and fetch messages, and drive an incremental change feed off the `updated_since` watermark.
  </Card>

  <Card title="Usage & billing" icon="file-invoice-dollar" href="/api-reference/v2/usage/usage-summary">
    Portfolio usage summaries, individual billing records, and per-period statements.
  </Card>

  <Card title="Webhook signing" icon="shield-check" href="/api-reference/v2/webhooks/signing">
    Verify the HMAC-SHA256 signature on every delivery, reply, and opt-out event.
  </Card>

  <Card title="Idempotency" icon="rotate" href="/api-reference/v2/idempotency">
    Safely retry `POST` requests with an `Idempotency-Key` without creating duplicates.
  </Card>

  <Card title="Sandbox & testing" icon="flask" href="/api-reference/v2/sandbox">
    Simulate sends and signed webhooks with a test key — no delivery, no billing.
  </Card>
</CardGroup>

## Typical integration flow

1. **Provision a business.** [Create a child account](/api-reference/v2/accounts/create-child) with your own identifiers in `externalIds`, then [mint a child API key](/api-reference/v2/accounts/create-api-key).
2. **Configure webhooks.** [Register a webhook endpoint](/api-reference/v2/webhooks/create-endpoint) for the child and store its signing secret so you can [verify signatures](/api-reference/v2/webhooks/signing).
3. **Send.** Use the child key with the standard [send](/api-reference/v2/messages/send-single) endpoints. [Preflight](/api-reference/v2/messages/preflight) first if you want to check eligibility and cost without sending.
4. **Reconcile.** Poll [messages](/api-reference/v2/messages/list-messages) and [billing records](/api-reference/v2/usage/billing-records) with the `updated_since` / `updatedSince` watermark to keep your mirror in sync.

## Test before you go live

Build against a [sandbox key](/api-reference/v2/sandbox) first: sends run every live gate (ownership, suppression, opt-in, BYOC) and return a simulated result — and a single sandbox send fires a real, signed webhook to your endpoint so you can prove your signature verification end-to-end before a single real message goes out.