Skip to content
All documentation chapters
On this page

Supra Core API — Public Client Documentation

Chapter 18 — Support

1. Purpose

This chapter explains how to prepare a useful, sanitized support request for Supra Core API service issues.

Use only the support channel supplied by TCP Labs with your access. Plan details and commercial terms are provided separately; public documentation does not grant access or publish an unverified support address.

2. Before Escalating

Check:

  • the request uses HTTPS;
  • the method and endpoint are documented;
  • X-API-Key is configured on the trusted backend;
  • required parameters are present;
  • integer and enum values are valid;
  • limit and offset are within documented behavior;
  • a valid empty or null result is not being mistaken for an outage;
  • bounded retry and backoff were applied only where appropriate.

3. Information to Include

Provide:

  • UTC request time;
  • HTTP method;
  • endpoint path;
  • non-secret query parameters;
  • HTTP status;
  • public error.code;
  • <request-id> when the response provides one;
  • whether the issue is consistent or intermittent;
  • expected behavior;
  • observed public-safe behavior;
  • client runtime and relevant library version when useful.

4. Information Never to Include

Never send:

  • API keys;
  • authorization headers;
  • wallet private keys or seed phrases;
  • passwords;
  • session tokens;
  • private server paths or host details;
  • unrelated credentials;
  • complete logs that have not been redacted.

Warning: If an API key appears in a ticket, chat, screenshot, command, or log, treat it as exposed and follow the approved key-replacement process.

5. Sanitized Report Template

UTC time: <utc-timestamp>
Method: GET
Endpoint: <endpoint>
Network: mainnet
Query parameters: <redacted-non-secret-parameters>
HTTP status: <status>
Public error code: <public-error-code-or-none>
Request identifier: <request-id-or-not-provided>
Expected: <short-description>
Observed: <short-description>
Reproducibility: <consistent-or-intermittent>

Do not paste <api-key> into the completed report.

6. Common Support Categories

Category Useful context
Access or 401 Endpoint, UTC time, status, whether the key is configured server-side
Rate limit or 429 Endpoint, request pattern, concurrency, retry interval
Invalid request or 400 Endpoint and sanitized parameters
Route or method Exact path and HTTP method
Temporary 500 UTC time, endpoint, retry count, public error code
Empty data Endpoint, filters, offset, expected source family
Stale data Endpoint, latest event time, as-of time, client freshness threshold
Precision issue Field name, raw JSON type, expected formatting

7. Reproduction Guidance

Use the smallest safe request that reproduces the issue:

  • one endpoint;
  • minimum required parameters;
  • a bounded limit;
  • placeholders in shared documentation;
  • no private key or credential;
  • no unrelated response data.

If the issue concerns FA or LEGACY data, state the source family explicitly.

8. Response Expectations

Support can use sanitized public context to investigate. This chapter does not promise:

  • a specific response time;
  • restoration of unavailable historical data;
  • support for undocumented behavior;
  • disclosure of private infrastructure or implementation;
  • acceptance of secret-bearing reports.

9. Scope and Data Exposure

Support requests should include only sanitized, client-visible context. Never send API keys, secret-bearing logs, or other private credentials.

10. Chapter Summary

Before escalating, verify the documented request and error behavior. Send only sanitized endpoint, time, status, public error, and reproduction context through the approved support channel. Never send API keys or other secrets.