Skip to content

Core Endpoints — Launch Monitor & Session Partners

These integrations cover hardware launch monitors (e.g., Trackman, FlightScope, Foresight GCQuad, Garmin R10, Rapsodo MLM2PRO) and simulator platforms (e.g., GSPro, Full Swing) that produce ball-flight and club-delivery telemetry during practice sessions.

Your API must expose the following endpoints (or functional equivalents) for us to build a working integration.

POST/oauth/authorize

Initiate the OAuth flow; redirect the user to your consent screen.

POST/oauth/token

Exchange authorization code for access + refresh tokens.

POST/oauth/token/refresh

Refresh an expired access token without user interaction.

GET/users/me

Return the authenticated user’s profile. Must include a stable, unique user identifier.

GET/sessions

List practice sessions for the authenticated user.

  • Should support date-range filtering (?startDate=&endDate=). Required for production-scale background sync.
  • Should support pagination. Required for users with large session histories.
  • Response should include session-level metadata: session ID, start time, end time, device model, and shot count.
GET/sessions/{sessionId}

Return full detail for a single session, including all shots.

GET/sessions/{sessionId}/shots

Return the ordered list of shots within a session.

  • Each shot must include a unique shotId.
  • Shots must be ordered by timestamp or sequence index. Our processing pipeline depends on correct shot ordering.
POST{your_callback_registration_endpoint}

Register a webhook URL where your system notifies AVA of session lifecycle events. This is the preferred integration pattern because it eliminates polling and gives users near-instant data availability.

  • Required events: session.completed required (session finished and saved).
  • Strongly recommended events: session.edited (user modifies a past session), session.deleted (user removes a session).
  • Should include an HMAC signature header (or equivalent) for payload verification.

Two payload styles are supported — choose whichever fits your architecture:

  1. Full payload: Webhook body contains the complete session with all shots. Preferred when feasible.
  2. Notification + fetch: Webhook body contains the session ID (and optionally a callback URL); AVA retrieves full data via your REST endpoints. This is equally acceptable — it is how several of our production integrations work.