Developers

TRIGR Partner API access is invite-only. Staff create Partner organizations and contacts. Authorized contacts accept the Partner API Terms before any API credential (sandbox or production) can be claimed.

What lives here

• Partner API Terms, portal onboarding, and credential claim rules.
• OpenAPI 3.1 contract for Partner v1 (matches, participants, results, webhooks).
• Sandbox and production are separate App Runner hosts. Keys must match the host.

Current Partner API Terms

Version 1.0, effective 2026-08-22. Read the Partner API Terms. Accepting Terms does not grant scopes or production access. Staff still authorize those.

OpenAPI

Machine-readable contract (OpenAPI 3.1): /developers/openapi.yaml. Also served from the API as GET /api/v1/openapi.yaml.

Authentication

Pass the full API secret as a Bearer token. Never put secrets in query strings or paths. Example (obviously fake):

curl -sS \
  -H "Authorization: Bearer trigr_test_examplePublicId_notARealSecretUseYourOwn" \
  -H "Accept: application/json" \
  https://SANDBOX_API_HOST/api/v1/me

Sandbox credentials start with trigr_test_. Production credentials start with trigr_live_. A test key against production (or the reverse) is rejected before any domain access.

Authorization model

• Scopes: what type of operation (matches.read, match-results.write, webhooks.manage, …).
• Resource grants: which match, or which private shooter profile.
• Property allowlists: which fields on the wire.

Importing or managing a match can authorize competition participants and results for that match. It does not unlock private TRIGR account profiles. Those need an explicit Partner→Shooter grant from staff (shooter consent later).

Resources (v1)

• GET /api/v1/me · GET /api/v1/scopes
• GET/POST /api/v1/matches · GET /api/v1/matches/{id}
• POST /api/v1/matches/{id}/participants
• GET/POST /api/v1/matches/{id}/results
• GET/POST /api/v1/webhooks/endpoints

Writes support Idempotency-Key. Same key and same body replays the original result. Same key and a different body returns 409.

JavaScript example

const res = await fetch("https://SANDBOX_API_HOST/api/v1/matches", {
  method: "POST",
  headers: {
    Authorization: `Bearer ${process.env.TRIGR_PARTNER_KEY}`,
    "Content-Type": "application/json",
    "Idempotency-Key": "club-match-2026-08-01-create",
  },
  body: JSON.stringify({
    externalId: "club-match-2026-08-01",
    name: "Saturday Classifier",
    matchDate: "2026-08-01",
    discipline: "uspsa",
  }),
});

Python example

import os, requests

r = requests.get(
    "https://SANDBOX_API_HOST/api/v1/matches",
    headers={"Authorization": f"Bearer {os.environ['TRIGR_PARTNER_KEY']}"},
    timeout=30,
)
r.raise_for_status()
print(r.json())

Errors and rate limits

Expect normal HTTP status codes: 401 for bad or wrong-environment credentials, 403 for missing scope or resource grant, 404 when the resource is not visible to your partner, 409 for idempotency conflicts, 429 when you outrun your plan. Responses include a request id when practical. Stack traces stay on our side.

Webhooks

Outgoing events include match.created, match.updated, and match.results.updated. Endpoints must be HTTPS in production. We sign bodies with HMAC-SHA-256 using a separate webhook signing secret (not your API key). Headers: TRIGR-Webhook-Id, TRIGR-Webhook-Timestamp, TRIGR-Webhook-Signature (v1=hex). Reject stale timestamps (about five minutes) and replayed event ids on your side. Private and metadata destinations are blocked (SSRF).

Partner Portal

Authorized contacts sign in at /partners/portal with an email magic link. Claim and rotate API secrets there. Consumer TRIGR accounts are not used for portal access.

Changelog

Partner API changes are tracked separately from app What's New. v1.0.0: invite-only platform, match/participant/result resources, idempotency, rate plans, webhooks foundation, OpenAPI 3.1.

Consumer vs Partner

Ordinary TRIGR app use is covered by the Consumer Terms of Service and Privacy Policy.