API Key Authentication

Using UGSK_ developer API keys for server-side integration

Updated October 3, 2026

Server-side integrations authenticate with a single API Key (UGSK_...). The same key system backs both `/developer/api-keys` (any authenticated user - business, developer, or Solution Partner) and `/partners/api-keys` (Solution Partners). Keys issued through either endpoint use the same format - there is no separate "partner" key prefix.

Key format

code

UGSK_live_<64-hex>   # your API Key
UGSK_test_<64-hex>   # test environment (not currently issuable)

LIVE by default. Every key issued today is a live key - there is no sandbox to execute against. The test segment is reserved in the key format for a future TEST environment; do not build an integration that assumes one is available now.

These keys are not filtered by the Actions Gateway OAuth scope ladder. A key can call the campaign and slot routes the account is allowed to call. Automation OAuth access tokens are different: they only pass scopes granted at consent (campaign:read / write / fund / discover, slot:read / write, earnings:read, wallet:read, username:read, crypto:deposit, hooks:manage, payout:transfer). Portal session JWTs are also not scope-filtered that way.

All authenticated requests:

http

Authorization: Bearer UGSK_live_<key>
Content-Type: application/json

Your API Key is server-side only. Never expose it in client-side JavaScript, mobile bundles, or public repositories. Store it in environment variables and a secrets manager.

Managing keys

Action	Endpoint
Create a key	`POST /developer/api-keys` - body: `{ "name": string, "environment"?: "TEST" \	"LIVE" }`
List keys	`GET /developer/api-keys`
Revoke a key	`DELETE /developer/api-keys/:id`

The create response includes the raw key once (key) alongside id, name, environment, keyPreview, and createdAt - store it immediately, it is not retrievable again. The list response returns keyPreview/keyPrefix only, never the raw key.

Solution Partners use the identical flow at POST /partners/api-keys, GET /partners/api-keys, DELETE /partners/api-keys/:id.

Idempotency

On create operations you may send:

http

Idempotency-Key: <unique-string>

The same key returns the existing resource on retry.

Security best practices

Never expose your API Key in:

Client-side JavaScript (browser)
Public repositories (GitHub, GitLab)
Browser console logs
Error messages shown to users
URL parameters or query strings

Always:

Store keys in environment variables
Use .gitignore for env files
Rotate keys from API Keys in the Developer Console when staff change
Revoke compromised keys immediately with DELETE /developer/api-keys/:id or from the same page

Rate limits

Limits may vary by key and product configuration. Treat `429 Too Many Requests` as a signal to back off with exponential retry and respect Retry-After when present. See also Errors.

API Key authentication is indicated by a lock icon in endpoint documentation.

Did this solve your problem?