Skip to main content

API Keys

API keys let external tools act as your authenticated PredictDog app user on supported routes.

PredictDog API key management

The current web API key page is built specifically for agents and automation. Users can create a named key, choose an expiry, see token previews, and revoke old keys from one place.

Typical use cases​

  • personal scripts
  • internal agents
  • automation tools
  • lightweight integrations that need account-backed API access

Where to create them​

Create and manage keys on web in Settings -> API Keys.

Current UI behavior:

  • keys are issued from the signed-in web session
  • the raw token is shown only once after creation
  • existing keys can be reviewed by name, preview, created time, last-used time, expiry, and status
  • keys can be revoked individually when no longer needed

Current scope model​

The current web page shows these integration scopes:

  • account:read
  • portfolio:read
  • trade:polymarket
  • trade:predict
  • trade:memecoin

Today, the product UI presents API keys as full integration credentials for supported user-level routes. Users should still validate the exact route their tool depends on instead of assuming every scope behaves the same way.

Best practice​

  1. Create a key from the web product.
  2. Test it against a safe read endpoint first.
  3. Use only the key you need.
  4. Revoke and rotate immediately if it is exposed.

Safe rollout pattern​

Use this progression:

  1. Mint the key.
  2. Verify it against a read endpoint such as the authenticated account check.
  3. Test the exact route your integration needs.
  4. Only then connect it to an agent or automation workflow.

This reduces confusion between a bad credential and a route-specific behavior mismatch.

Important rule​

API keys are for calling supported application routes. They are not a replacement for the signed-in web session used to manage the keys themselves.

Important boundary​

API keys are app-user credentials, not wallet-authority credentials.

That means they are the right tool for supported read and trade routes, but not for sensitive wallet-management actions such as withdraw, export, or other fresh-authorization flows.

Common mistakes​

  • using an API key to manage API keys instead of using the web session
  • assuming every route behaves the same way without testing the exact endpoint
  • keeping an exposed key alive after it has been pasted into logs, prompts, or the wrong integration