How to Use gpt-6-astra via the hiapi API: curl, Python, and a Working Request

gpt-6-astra is a reasoning-capable text model live on hiapi today, reachable through a single OpenAI-compatible endpoint: /v1/responses. This guide gives you a working curl and Python request, the one non-obvious requirement that trips people up (streaming is mandatory), and the production patterns you need before shipping it.

What you'll build

A script that sends a prompt to gpt-6-astra and reads back the model's answer over a streamed response. There's no polling and no task id — this is a synchronous chat-style call, just delivered as Server-Sent Events instead of one blocking JSON response.

Prerequisite: an hiapi API key. Grab one from the dashboard — every request below needs it in the Authorization header.

Minimal working example

gpt-6-astra only supports one endpoint — POST /v1/responses — and it only accepts "stream": true. Sending "stream": false returns a 400 invalid_request error no matter what else is in the payload; the model has no non-streaming mode on hiapi. Plan your client around reading an event stream, not around a single JSON response.

curl

curl -N -X POST "https://api.hiapi.ai/v1/responses" \
  -H "Authorization: Bearer sk-your-api-key" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gpt-6-astra",
    "input": [
      {
        "type": "message",
        "role": "user",
        "content": [
          { "type": "input_text", "text": "Explain one practical way to check an AI-generated answer against its source." }
        ]
      }
    ],
    "stream": true,
    "store": false,
    "reasoning": { "effort": "medium" }
  }'

-N disables curl's output buffering so you see events as they arrive instead of all at once at the end. The response is text/event-stream, one JSON object per data: line, with an event: line naming its type. A trimmed run looks like this:

event: response.created
data: {"type":"response.created","response":{"id":"resp_...","status":"in_progress", ...}}

event: response.output_text.delta
data: {"type":"response.output_text.delta","delta":"OK", ...}

event: response.completed
data: {"type":"response.completed","response":{"status":"completed","usage":{"input_tokens":12,"output_tokens":5,"total_tokens":17}, ...}}

The text you actually want streams in through repeated response.output_text.delta events — concatenate the delta fields in order to get the full answer. response.completed carries the final usage block for cost tracking.

Python

import json
import requests

payload = {
    "model": "gpt-6-astra",
    "input": [
        {
            "type": "message",
            "role": "user",
            "content": [
                {
                    "type": "input_text",
                    "text": "Explain one practical way to check an AI-generated answer against its source.",
                },
            ],
        },
    ],
    "stream": True,
    "store": False,
    "reasoning": {"effort": "medium"},
}

with requests.post(
    "https://api.hiapi.ai/v1/responses",
    headers={
        "Authorization": "Bearer sk-your-api-key",
        "Content-Type": "application/json",
    },
    json=payload,
    stream=True,
    timeout=60,
) as resp:
    resp.raise_for_status()
    answer = []
    for line in resp.iter_lines():
        if not line or not line.startswith(b"data: "):
            continue
        event = json.loads(line[len(b"data: "):])
        if event.get("type") == "response.output_text.delta":
            answer.append(event["delta"])
        elif event.get("type") == "response.completed":
            usage = event["response"]["usage"]
            print(f"\n\ntokens: {usage['input_tokens']} in / {usage['output_tokens']} out")

    print("".join(answer))

resp.raise_for_status() catches HTTP-level failures (auth, rate limits) before you start parsing SSE lines — a malformed stream is a different failure mode than a rejected request, and you want to tell them apart in your error handling.

Two fields worth calling out in the payload:

• input is an array of message objects, not a flat string — each item needs type: "message", a role, and a content array of typed parts (input_text for plain text).
• reasoning.effort (low / medium / high) is optional but controls how much internal reasoning the model does before answering. Leave it out and hiapi applies a default; set it explicitly if you're tuning latency vs. answer quality.

Production notes

• Streaming is not optional. Don't build a code path that falls back to stream: false on retry — it will fail every time for this model. If your framework or SDK assumes a single JSON response, wrap the SSE loop above and buffer the concatenated text before handing it off.
• Auth failures are explicit. A bad or revoked key returns HTTP 401 with "code": "permission_denied" in the error body — check for that code rather than pattern-matching the message string, which can change.
• store: false keeps requests stateless. hiapi won't retain the response server-side, so there's no previous_response_id to chain against on a later call. If you need multi-turn context, resend prior turns as additional input messages rather than relying on server-side conversation state.
• Set a client-side timeout regardless of streaming. SSE connections can hang on a dropped connection without either side sending a clean close; a timeout on the initial requests.post (as in the example above) protects against a stalled first byte, but you should also track a max stream duration in your own code for defense in depth.
• Reuse prompt_cache_key for repeated system context. The response payload includes a prompt_cache_key; if you're sending the same instructions on every call, keeping requests on the same key lets hiapi apply prompt caching instead of re-processing them each time.

Related reading

• gpt-6-astra model page — full parameter reference and live pricing
• hiapi API docs — auth, other model families, and the full endpoint list
• hiapi pricing — per-token rates for gpt-6-astra and every other model

FAQ

Does gpt-6-astra support /v1/chat/completions? No. Calling it through /v1/chat/completions returns a 400 unsupported_endpoint error telling you to use /v1/responses instead. It's only registered for the Responses API on hiapi.

Can I get a single JSON response instead of a stream? Not for this model. "stream": false is rejected outright (invalid_request), with or without other parameters set. Build your integration around consuming the SSE stream and assembling the final text client-side, as shown above.

Does gpt-6-astra support tool calling? The model accepts a tools array in the Responses API request shape (visible as an empty array in the response object when unset). If you're wiring up function calling, define your tools the same way you would for any OpenAI Responses-API-compatible model and watch for response.output_item.added events with a function_call type in the stream.

What does a rate limit or quota error look like? Like other hiapi errors, it comes back as JSON with type: "hiapi_error" and a code field you can branch on, plus a request_id — include that id when contacting support so they can trace the exact request server-side.

Can I use the same request shape for other reasoning models on hiapi? The /v1/responses request shape is shared across hiapi's OpenAI-Responses-compatible model family — swap the model field to switch models. Availability varies by model, so check each model's own page before assuming it's live.