Search
K

Get Platform Access

This guide explains the information required to provision Galaxy REST API access and the path from request to active credentials.

1. Access Model Overview

Galaxy API access is provisioned per organization and environment. Your team receives machine-to-machine OAuth credentials used to request access tokens.

At a minimum, you will receive:

  • client_id
  • client_secret
  • Environment(s) approved for your integration
  • API scope and access policy mapping

2. Information To Prepare

Before requesting access, gather the following:

  • Legal entity and primary business contact
  • Technical owner (name, email, team)
  • Product/API families required (for example: Prime Services, OTC Trading, Staking, Onchain Execution Service)
  • Target environments (UAT, Production)
  • Expected launch timeline
  • High-level use case and expected traffic profile

Discovery inputs that should be confirmed early:

  • Account and settlement model assumptions (including pre-funded spot workflow)
  • Product scope by phase (spot, custody, staking, lending, margin)
  • Custody operating constraints (deposit/withdrawal controls, whitelisting, approval thresholds)
  • Event integration requirements (webhook endpoints, verification, replay/retry handling)
  • Reconciliation and reporting expectations

Recommended to include upfront:

  • Source egress IP ranges (if allow-listing is required)
  • Operational contact for incident notifications
  • Security contact for credential rotation and controls

3. Provisioning Workflow

  1. Submit your integration request through your Galaxy relationship manager or implementation contact.
  2. Galaxy reviews your requested APIs and environment scope.
  3. OAuth client credentials are generated for approved environment(s).
  4. Access policies (consumer groups / ACLs) are applied for allowed APIs.
  5. Your team validates auth and first API calls in a non-production environment.
  6. Production enablement is completed after readiness and controls review.

4. Environment-Specific Credentialing

Credentials are environment-bound. Do not reuse credentials across environments.

Use Environments for the canonical environment matrix and Authentication for token endpoint patterns and request details.

5. Security Requirements

Treat credentials as secrets and enforce production-grade handling from day one.

  • Store credentials in a secrets manager (not in code or plaintext config files)
  • Rotate secrets on a defined cadence and after personnel or incident events
  • Restrict access using least privilege principles
  • Use TLS-only transport for all API calls
  • Log auth and API failures with request correlation identifiers

6. Readiness Checklist

Before requesting Production access, confirm:

  • Integration is validated in UAT
  • Alerting and monitoring are in place for auth failures and API error rates
  • Retry/backoff strategy is implemented for 429 and transient 5xx
  • Token caching and proactive refresh are implemented
  • Runbooks exist for incident handling and credential rotation

Also confirm before production approval:

  • UAT coverage includes happy paths and failure-path controls
  • Reconciliation responsibilities and handoffs are documented
  • Operational escalation path and support model are agreed

7. Common Provisioning Delays

The most common causes of delay are:

  • Missing environment scope in the request
  • Incomplete API product scope
  • Missing technical owner and operations contacts
  • Production request submitted before UAT validation is complete

8. Next Steps

After you receive credentials:

  1. Validate endpoint connectivity in Environments.
  2. Execute Submit Your First API Call.
  3. Review Authentication for token handling best practices.