Skip to main content
The GcConnectService class (accessed via client.gcConnect) implements the Connect your GC Store flow — letting merchants authorize your application to access their store with a single click, no API key copying required.

Overview

When a merchant authorizes your application, Galactic Core provisions a key pair (sk + pk) scoped to their store and the permissions they granted. Those keys are permanent — they stay active until the merchant disconnects your app or you call connectRevoke. The flow in four steps:
  1. Redirect the merchant to https://gc.tybritelabs.com/connect/authorize with your client_id, redirect_uri, scope, and state.
  2. After the merchant approves, Galactic Core redirects to your redirect_uri with a short-lived code.
  3. Your server calls connectToken to exchange the code for sk + pk.
  4. The sk is held server-side and authenticates every subsequent API call made on that merchant’s behalf.
Your application must be approved by Galactic Core before you can use these endpoints. Apply via the Developer Portal.

Building the Authorization URL

Construct the URL yourself and redirect the merchant’s browser to it. The SDK provides getConnectAuthorize for validation/rendering, but the redirect itself is a browser navigation.
Available scopes (enforced per request — a key is rejected with 403 insufficient_scope if it calls an endpoint it wasn’t granted):

getConnectAuthorize

Validates an authorization request and returns the information the consent page needs to render. You typically do not call this from your integration — it is used by the hosted consent page. No authentication required.
Validation errors (unknown client_id, unregistered redirect_uri, invalid scopes) return a 400 response rather than a redirect, preventing open redirect attacks.

postConnectAuthorize

Records the merchant’s approval and returns the short-lived code to hand back to your redirect_uri. Like getConnectAuthorize, this is the hosted consent page’s counterpart — the submit to its render — and is not something your integration calls. Your integration receives the resulting code on the redirect and exchanges it with connectToken. Requires the merchant’s own session — it is their approval being recorded, so an anonymous call is rejected with 401.
The redirect_uri, scope, and state must match the values the authorization request was opened with; a mismatch is rejected rather than honoured, so an approval cannot be replayed against a different destination or widened to scopes the merchant never saw.

connectToken

Exchanges the one-time authorization code for the merchant’s API key pair. Call this from your server — never from a browser. The client_secret must never be exposed client-side.
Response
Store the sk and signing_secret securely server-side immediately — both are returned only once. The pk is safe to use client-side for read-only catalog and cart operations.
Signing write requests: creating/updating orders and initializing payments require a signature. Sign with the signing_secret from this response: set X-Timestamp to the current Unix time and X-Signature to the HMAC-SHA256 of `${timestamp}.${requestBody}`. This secret is scoped to this connection, so it can be rotated or revoked independently. Response fields: Error codes:

connectRevoke

Programmatically revokes a store connection — deactivates the key pair and records the disconnection. Use this when a merchant cancels their subscription on your platform or you otherwise need to disconnect them from your side.
Merchants can also disconnect your application at any time from their Integrations → Developer → Connected Apps panel. Galactic Core handles that automatically — you do not need to call this endpoint for merchant-initiated disconnects. Both paths deactivate the same key pair.

listConnectSessions

Returns all active connections for the authenticated store. This powers the Connected Apps section in the merchant’s settings panel. Requires a secret key (tybrite_sk_*).

Complete Integration Example


Response Codes