OAuth Flow (Lighthouse Token)

The Lighthouse Token Flow enables third-party integrations with Shift4 Marketplace through standard OAuth 2.0 authorization, allowing merchants to grant applications permission to make API calls on their behalf.

Overview

Before Lighthouse merchants can use your application, they need to grant it permission to make API calls on their behalf. Use OAuth for this purpose.

OAuth 2.0 provides secure, delegated access to the Shift4 Marketplace API. Merchants authenticate through the Lighthouse system and grant your application specific permissions. Your integration receives access tokens for API calls and refresh tokens for seamless re-authentication.

Key Features

  • Standard OAuth 2.0 - Industry-standard authorization code flow
  • Access Tokens - 24-hour validity for API authentication
  • Refresh Tokens - Long-lived tokens for obtaining new access tokens
  • Scoped Permissions - Granular control over API access
  • Secure Authentication - Bearer token authentication for all API calls

Flow Diagrams

OAuth + Retrieve Locations Flow

The diagram below presents a simplified OAuth + Retrieve Locations Request Flow sequence:

OAuth + Retrieve Locations Request Flow
  1. The merchant initiates a request to S4 LH Auth, providing its client ID, in order to obtain an authorization code.
  2. Upon receiving the request, LH Auth redirects the merchant back to the specified redirect URI, appending a code query parameter containing the authorization code.
  3. The merchant, having received the authorization code, proceeds to exchange it with S4 LH Auth in order to acquire an access token.
  4. S4 LH Auth responds to the merchant's request by providing an access token, which can be used for subsequent API calls.
  5. Using the obtained access token, the merchant makes a request to the Conecto API, specifically asking for a list of LH User Locations.
  6. The Conecto API processes the request and returns a response containing the requested list of User Locations.

Activate Location Flow

The diagram below presents a simplified activate Location Request Flow sequence:

Activate Location Request Flow
  1. The Merchant sends a request to the S4 Conecto API, requesting the installation of an integration for a specific location. The request includes the LH User Access Token, which serves as an authorization credential.
  2. Upon receiving the request, the S4 LH OAuth validates the provided Access token in the middleware of the Conecto API. This validation process ensures that the token is valid and authorized to access the requested resources.
  3. After successful validation, the Conecto API proceeds to install the integration for the requested location. Once the installation is completed, the API sends a response with a status code of 204, indicating a successful operation without any content in the response body.

Authorization Process

Step 1: Initiate OAuth Flow

Direct merchants to the authorization endpoint with required parameters:

https://lighthouse-api.harbortouch.com/oauth2/authorize/?client_id=YOUR_CLIENT_ID&redirect_uri=https://yourapp.com/callback&response_type=code

Required Parameters:

ParameterDescription
client_idYour application's Client ID (provided by Shift4)
redirect_uriYour registered callback URL
response_typeAlways set to code for authorization code flow

At this URL, the Merchant will see a login screen:

OAuth Login Screen

The permissions form is displayed when the Merchant signs in to Lighthouse:

OAuth Permission Screen

The permissions form shows which permissions the application is requesting. If the merchant is comfortable with the permissions listed, they click Allow. Otherwise, they click Deny. In either case, the merchant will be redirected back to your provided redirect_uri.


Step 2: Handle Authorization Response

Success - Merchant Approves Access

When a merchant approves, they're redirected to your callback URL with an authorization code:

https://yourapp.com/callback?code=AUTHORIZATION_CODE

Exchange this code for access and refresh tokens:

Method: POST

Endpoint: /oauth2/token/

Content-Type: application/json

Exchange the authorization code for access and refresh tokens.

Request

POST
/oauth2/token/
curl -X POST https://lighthouse-api.harbortouch.com/oauth2/token/ \
  -H "Content-Type: application/json" \
  -d '{
    "grant_type": "authorization_code",
    "code": "AUTHORIZATION_CODE",
    "redirect_uri": "https://yourapp.com/callback",
    "client_id": "YOUR_CLIENT_ID",
    "client_secret": "YOUR_CLIENT_SECRET"
  }'

Response

{
  "access_token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...",
  "refresh_token": "refresh_abc123xyz789...",
  "permissions": ["read:locations", "write:installations"],
  "expiration": 86400,
  "token_type": "Bearer"
}

Denial - Merchant Denies Access

If the merchant denies access, they're redirected with an error parameter:

https://yourapp.com/callback?error=access_denied

Handle this gracefully by displaying an appropriate message to the merchant.


Token Management

Access Token Usage

Include the access token in every API request header:

curl -X GET https://lighthouse-api.harbortouch.com/api/v1/locations/ \
  -H "Authorization: Bearer YOUR_ACCESS_TOKEN"

Token Details:

  • Access tokens expire after 24 hours
  • Token type is always Bearer
  • Include in the Authorization header for all API requests
  • Store securely (encrypted at rest)

Refresh Expired Tokens

When access tokens expire (indicated by a 401 Unauthorized response), use the refresh token to obtain a new access token:

Method: POST

Endpoint: /oauth2/token/

Content-Type: application/json

Exchange your refresh token for a new access token without requiring the merchant to re-authorize.

Request

POST
/oauth2/token/
curl -X POST https://lighthouse-api.harbortouch.com/oauth2/token/ \
  -H "Content-Type: application/json" \
  -d '{
    "grant_type": "refresh_token",
    "refresh_token": "USER_REFRESH_TOKEN",
    "client_id": "YOUR_CLIENT_ID",
    "client_secret": "YOUR_CLIENT_SECRET"
  }'

Response

{
  "access_token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...",
  "refresh_token": "refresh_abc123xyz789...",
  "permissions": ["read:locations", "write:installations"],
  "token_type": "Bearer"
}

API Endpoints

Retrieve Eligible Locations

Returns all locations where the merchant can install your integration.

Method: GET

Endpoint: /marketplace/v2/lighthouse-token/locations

Authentication: Bearer token required

Use this endpoint after obtaining an access token to display available locations to the merchant.

Request

GET
/marketplace/v2/lighthouse-token/locations
curl -X GET https://conecto-api.shift4payments.com/marketplace/v2/lighthouse-token/locations \
  -H "Authorization: Bearer YOUR_ACCESS_TOKEN"

Response

{
  "results": [
    {
      "id": 12345,
      "name": "Downtown Restaurant",
      "timeZone": "America/New_York",
      "merchantId": "MERCH-12345",
      "countryCode": "US",
      "currency": "USD",
      "language": "en",
      "brandRef": "skytab",
      "address": {
        "street": "123 Main St",
        "city": "New York",
        "state": "NY",
        "zipCode": "10001"
      }
    }
  ],
  "meta": {}
}

Install Integration

Installs your integration for a specific location.

Method: POST

Endpoint: /marketplace/v2/lighthouse-token/installations

Authentication: Bearer token required

Content-Type: application/json

Submit installation for the selected location. The merchant must have granted appropriate permissions.

Request

POST
/marketplace/v2/lighthouse-token/installations
curl -X POST https://conecto-api.shift4payments.com/marketplace/v2/lighthouse-token/installations \
  -H "Authorization: Bearer YOUR_ACCESS_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "locationId": 12345
  }'

Response

204 No Content

Best Practices

  • Name
    Secure Token Storage
    Description

    Store access and refresh tokens encrypted at rest in a secure database or vault. Never expose tokens in logs or client-side code.

  • Name
    Automatic Token Refresh
    Description

    Implement automatic token refresh before expiration. Monitor for 401 errors and refresh tokens immediately when detected.

  • Name
    HTTPS Only
    Description

    Always use HTTPS for OAuth endpoints and redirect URIs. Never use HTTP in production environments.

  • Name
    State Parameter
    Description

    Include a state parameter in authorization requests to prevent CSRF attacks. Validate the state on callback.

  • Name
    Error Handling
    Description

    Handle both approval and denial scenarios gracefully. Provide clear messaging to merchants about access requirements.

  • Name
    Redirect URI Validation
    Description

    Ensure your redirect URI exactly matches the URI registered with Shift4. Mismatches will cause authorization failures.

  • Name
    Cache Location Data
    Description

    Cache location data to reduce API calls. Refresh periodically or when webhooks indicate changes.

  • Name
    Exponential Backoff
    Description

    Implement exponential backoff for failed API requests to avoid overwhelming the API during outages.

Was this page helpful?