Supra Core API — Public Client Documentation

Chapter 02 — Getting Access

1. Purpose

This chapter explains how to request and test access to the authenticated commercial Supra Core API service. Public documentation and the OpenAPI specification do not grant access to the service.

---

2. Before Requesting Access

Prepare a concise description of:

• the organization or project requesting access;
• the intended client type, such as backend, dashboard, bot, or analytics job;
• the endpoint families expected to be used;
• the expected request volume and polling interval;
• the public network required;
• a technical contact for access and incident communication.

Do not send:

• wallet private keys or signing material;
• user passwords;
• unrelated credentials;
• production secrets;
• confidential data that is not needed to understand the integration.

---

3. Requesting Access

Use the access channel supplied by TCP Labs for your integration. Available plans, rate limits, permitted usage, and commercial terms are provided separately. This documentation does not promise a free tier or an automated checkout.

Access arrangements can differ by client. Do not assume that another client's:

• API key;
• request limits;
• allowed usage;
• endpoint coverage;
• support path

also apply to your integration.

---

4. Information You May Receive

A completed onboarding can provide:

• the HTTPS <api-base>;
• one <api-key>;
• applicable request-limit guidance;
• supported network information;
• an approved support or escalation channel;
• any client-specific access conditions.

Important: Treat <api-key> as a secret from the moment it is delivered.

---

5. Secure Key Delivery and Storage

The API key should be delivered through an approved secure channel and stored only in a trusted server-side environment.

Recommended pattern:

client app or frontend
        |
        v
client-owned backend or proxy
        |
        v
Supra Core

Do not embed the key in:

• browser JavaScript;
• mobile application bundles;
• public repositories;
• screenshots;
• URLs or query parameters;
• support messages;
• client-visible configuration.

---

6. First Access Test

Use the health endpoint from a trusted backend or terminal:

curl -sS \
  -H 'Accept: application/json' \
  -H 'X-API-Key: <api-key>' \
  '<api-base>/api/v1/health'

Expected outcomes:

A successful health request confirms basic access. It does not prove that every dataset is fully current.

---

7. Client Integration Checklist

• Use the supplied HTTPS <api-base>.
• Store <api-key> only on a trusted backend.
• Send the key through X-API-Key.
• Alternatively use Authorization: Bearer <api-key> when that header is preferable for the client.
• Verify /api/v1/health.
• Test one bounded data request.
• Preserve decimal precision.
• Handle null, empty arrays, and added fields.
• Implement caching and bounded retry.
• Confirm expected request volume against access guidance.
• Keep support reports free of secrets.

---

8. Access Problems

When requesting help, provide only sanitized context:

• request time in UTC;
• HTTP method and endpoint;
• public status and error code;
• relevant non-secret query parameters;
• <request-id> when the response supplies one;
• a short description of expected and observed behavior.

Never send the API key itself.

---

9. Scope and Data Exposure

This chapter covers requesting access, receiving the base URL and credential through approved channels, securing the credential, and verifying authenticated access. Provider-side administration is outside its scope.

---

10. Chapter Summary

Request access with a clear integration description, receive the HTTPS base URL and API key through approved channels, store the key on a trusted backend, and verify access with a bounded health request. Never expose the key in public client code or support material.