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

# Open-tracking pixel

> Public engagement endpoint embedded in delivered HTML mail.
No caller credentials — authenticity is an HMAC tag in `t`
(keyed by the platform tracking secret). Path suffix is typically
`<uuid>.gif`. Invalid tags still return the 1×1 GIF but are not recorded.




## OpenAPI

````yaml /api-reference/specs/email.yaml get /v1/track/open/{message_id_gif}
openapi: 3.0.3
info:
  title: Basaltic Email API
  version: 1.0.0
  description: >
    Customer-facing email sending API — regional. Covers sender-identity

    management + DNS-based verification (ownership + DKIM), the send API,

    suppression lists, templates, configuration sets, and IP pools.


    Each region is independent: an identity verified in `dev` is not verified

    in `sa-saopaulo-1` — the DKIM key + verification token are per-region, and
    the

    customer must re-verify in each region they want to send from.


    Verification flow:
      1. POST /v1/identities {name: example.com}
         → stamps a pending row, provisions a per-identity DKIM signing key,
           and returns the DNS records the customer must publish.
      2. Customer publishes the records at their DNS provider.
      3. POST /v1/identities/{id}/verify
         → server resolves the records, flips status=verified on a match.
           Only verified identities may send.
  contact:
    name: Basaltic Support
    email: ping@basaltic.sh
  license:
    name: Proprietary
    url: https://basaltic.sh/terms
servers:
  - url: https://email.{region}.basaltic.sh
    description: Regional API endpoint
    variables:
      region:
        default: sa-saopaulo-1
        description: Region code
security:
  - SignatureAuth: []
tags:
  - name: Email
    description: Customer-facing email sending (regional).
paths:
  /v1/track/open/{message_id_gif}:
    get:
      tags:
        - Email
      summary: Open-tracking pixel
      description: >
        Public engagement endpoint embedded in delivered HTML mail.

        No caller credentials — authenticity is an HMAC tag in `t`

        (keyed by the platform tracking secret). Path suffix is typically

        `<uuid>.gif`. Invalid tags still return the 1×1 GIF but are not
        recorded.
      operationId: trackOpen
      parameters:
        - name: message_id_gif
          in: path
          required: true
          schema:
            type: string
        - name: t
          in: query
          required: false
          schema:
            type: string
          description: Truncated HMAC tag covering (open, message_id).
      responses:
        '200':
          description: 1x1 GIF (or empty) tracking response.
        '404':
          description: Unknown message.
      security: []
components:
  securitySchemes:
    SignatureAuth:
      type: apiKey
      in: header
      name: Authorization
      description: >
        Request signing with an access key issued to a service account. An

        HMAC-SHA256 over a canonical form of the request, close to AWS SigV4.

        The `basaltic` CLI signs for you.


        Send `Authorization`, `X-Date` (UTC, `YYYYMMDDTHHMMSSZ`) and `X-Nonce`

        (random per request); add `X-Content-Sha256` to bind a body, and

        `X-Amz-Security-Token` when using temporary credentials.


        ```

        Authorization: BASALTIC-HMAC-SHA256
        Credential=<access_key_id>/<date>/<region>/basaltic/basaltic_request,
        SignedHeaders=host;x-date;x-nonce, Signature=<hex>

        ```


        `<region>` is the region code you are calling, or `global` for the
        global

        services. A signature is valid for 5 minutes from `X-Date`, and mutating

        requests are replay-guarded on the nonce.


        **Full signing procedure, including a working implementation:**

        https://docs.basaltic.sh/authentication


        ## Rate limits

        There is no global request budget. A limit applies only where an

        operation documents a `429`, and that operation says what it counts.

        Those responses carry `X-RateLimit-Limit`, `X-RateLimit-Remaining`,

        `X-RateLimit-Reset` and, on a `429`, `Retry-After` — read them rather

        than hard-coding a number. Retrying before `Retry-After` is refused and

        extends the window. Everything else is bounded by quota, not by request

        rate.

````