Skip to main content

Getting Started

Overview​

The Action Target POS Gateway provides endpoints for Point of Sale integration with SmartRange Axis systems.

Important: This API is only compatible with ranges using the SmartRange Axis platform. If you're unsure whether your range uses SmartRange Axis, please contact Action Target. This API is under active development—many features are already production-ready, and real-world usage will help inform future improvements.

Integration Flow​

Integration with SmartRange Axis follows a two-phase rollout approach. This allows you to validate core session management before adding event handling and lane purchasing.

Phase 1: Session Management​

Phase 1 focuses on giving your POS control over lane sessions. No webhook or products API is required.

Session Lifecycle​

Customer arrives → POS creates session → Customer uses lane → Session ends
  1. Customer checks in at POS - Staff selects a lane and duration
  2. Create session - POST /sessions with lane_id, group_id, duration, and customer_name
  3. Customer uses the lane - Session timer runs
  4. Modify session (optional) - Add/remove time via POST /sessions/{id}/modify?time=±minutes
  5. Session ends - Either timer expires, staff stops it via POST /sessions/{id}/stop, or it is ended via the SRA Control Screen

Important: During Phase 1, your POS does not receive real-time events. Sessions created or stopped from the SRA Control Screen will not trigger notifications to your system.

Phase 1 Limitations​

Sessions can be created or stopped from the SRA Control Screen (not via your POS). When this happens:

  • Your POS will not receive any notifications
  • The session will not appear in your POS's session list until the next poll

Recommended workaround: Poll GET /sessions periodically (e.g., every 30-60 seconds) to detect sessions that were created or stopped outside your POS.

Testing & Deployment​

  1. Sandbox testing - Develop and test your integration against the playground environment (playground.action-target.net)
  2. Production deployment - Once validated in sandbox, Phase 1 goes live on the production range
  3. Proceed to Phase 2 - After confirming Phase 1 is stable, we configure your webhook and products API

Phase 2: Events & Lane Purchasing​

Phase 2 adds real-time event notifications and optional lane purchasing capabilities.

Additional Setup​

  1. Configure webhook endpoint - Set up an HTTPS endpoint to receive events from Action Target
  2. Configure products endpoints - Set up an endpoint that returns your product catalog

Event Handling​

With your webhook configured, your POS will now receive real-time notifications:

  • Session lifecycle events - sessionCreated, sessionStarted, sessionStopped, etc.
  • Lane events - help, carrierHit, purchaseRequest

Handling External Changes​

Sessions can be created or stopped from the SRA Control Screen. When this happens:

  • You receive a sessionCreated or sessionStopped event immediately
  • No polling required—your webhook keeps you in sync

Lane Purchasing​

When lane purchasing is enabled, customers can request purchases directly from the lane UI:

  • Your products API provides the catalog displayed on the lane
  • Purchase requests arrive at your webhook for fulfillment
  • Time purchases automatically extend the session

Authentication​

Receiving Credentials​

Action Target should have provided your token and range-id for the simulation range with your onboarding email. Please contact Action Target if you have not received your credentials.

All gateway endpoints require two headers:

  • token: Range Server authentication token (UUID format)
  • range-id: Range identifier (UUID format)

These headers are omitted from request examples for brevity.

Environments​

EnvironmentBase URLPurpose
Playgroundhttps://playground.action-target.netDevelopment and testing
Productionhttps://api.action-target.netLive integration

Support​

For questions about this API or assistance with your integration, contact Action Target.

When reporting issues, please include:

  • The trace_id from any error responses
  • The endpoint and request payload (with sensitive data redacted)
  • Timestamp of when the issue occurred