How to use the TTAPI API: key to first request

TTAPI gives one account access to text, image, video, and music APIs. Begin in the TTAPI dashboard, create an API key, and store it in a server-side environment variable such as TTAPI_KEY. Do not expose the key in browser code, a public repository, screenshots, or client-side logs.

The platform key is shared across the catalog, but the header name is part of each API contract. For example, the OpenAI-compatible chat endpoint uses Authorization, while other TTAPI endpoints may document TT-API-KEY or a provider-compatible header. Copy the header from the exact reference page you are implementing.

• Create the key in the TTAPI dashboard.
• Store it in a server-only environment variable.
• Use the authentication header shown for the selected endpoint.
• Rotate the key if it is ever exposed.

Start with the result your product needs: a text answer, an image, a video, or a music track. Open the matching TTAPI model page to compare the current model IDs and supported workflows, then follow that model's documentation to select the endpoint. This keeps model availability, parameters, and pricing outside application code until you have verified the current contract.

For a first integration check, a non-streaming chat completion is useful because the response returns in the same HTTP request. This guide uses gpt-5.6-sol on the OpenAI-compatible /v1/chat/completions endpoint. You can switch to another supported OpenAI model by changing the model field after confirming its model page.

• Text: expect a response in the request or a stream when enabled.
• Images: check whether the selected endpoint returns a URL or encoded image data.
• Video and music: expect many workflows to return a job ID for later retrieval.
• Use the model page and API reference together before coding optional fields.

Set TTAPI_KEY in your server environment, then send the smallest request that proves authentication, routing, and response parsing. The example asks for a short checklist, sets stream to false, and uses only the required chat structure plus the selected model ID.

Keep the first prompt deterministic enough to review. A successful request should return an assistant message under choices and token usage for the request. Once this works, move the same call into your server route or backend service before connecting it to the product interface.

curl --request POST \
  --url 'https://api.ttapi.io/v1/chat/completions' \
  --header "Authorization: Bearer $TTAPI_KEY" \
  --header 'Content-Type: application/json' \
  --data '{
  "model": "gpt-5.6-sol",
  "messages": [
    {
      "role": "user",
      "content": "Return a three-item launch checklist for an AI feature."
    }
  ],
  "stream": false
}'

For this chat request, read the generated text from choices[0].message.content and retain the response ID, model, finish reason, and usage when they are present. Those fields make debugging and cost reviews easier than logging only the final text.

Handle authentication and validation errors separately from temporary failures. A 401 usually points to a missing or invalid key; a 400 usually means the body or model value needs correction. Use bounded retries for timeouts, rate limits, and selected server failures only when repeating the request is safe, and surface a stable error state to the user when retries end.

• Validate the HTTP status before reading generated content.
• Log a request or response ID without logging the API key.
• Record model and usage fields for operational review.
• Give validation, authentication, timeout, and provider failures distinct messages.

A working chat call proves the account and network path, but media generation can use a different request and result lifecycle. Some endpoints return media directly. Long-running video and music workflows commonly return a job identifier, then require a fetch request or a documented callback before the result is ready.

Persist an asynchronous job ID before the user leaves the page. Keep the original prompt, model ID, status, and result together, use a bounded polling interval when callbacks are not appropriate, and stop on success, failure, or your own timeout. Follow the selected endpoint's TTAPI reference for exact status values and storage limits.

• Save the job ID as soon as submission succeeds.
• Treat accepted and completed as different states.
• Make refresh and return visits recover the pending job.
• Review generated media before publishing it automatically.

Move to production with one model, one endpoint, and one measurable user task. Set request timeouts, cap retries, validate inputs before sending them, and prevent the browser from calling TTAPI with a secret key. If the product can create duplicate paid work, design the submit flow so reconnects and button presses do not silently send another generation.

After the path is observable and recoverable, add another model or modality. Keep model IDs and endpoint-specific fields behind a small server boundary so your interface does not have to change every time the catalog changes.

• Server-side key and request path
• Input validation and clear user-facing errors
• Timeouts and bounded retries
• Saved job state for asynchronous work
• Model, usage, latency, and failure monitoring
• A current pricing and documentation check before launch