HFAI Cloud · integration
Python
on HFAI Cloud.
base_url, api_key, and no other change.
Two keywords on the client.
Its own repository,
its own argument names.
The openai package is described in its own repository as the official Python library for the OpenAI API, and two of its constructor arguments decide where a request goes and who is making it: base_url and api_key. Both can be passed in directly, and the first can also arrive as the OPENAI_BASE_URL environment variable when a process should not carry the endpoint in its source. Checked against github.com/openai/openai-python.
from openai import OpenAI
client = OpenAI(
base_url="https://api.heartflowai.net/v1",
api_key="hfai_live_…",
)
reply = client.chat.completions.create(
model="gpt-oss:120b",
messages=[{"role": "user", "content": "Hello HFAI"}],
)
print(reply.choices[0].message.content)
Two arguments and an install are the whole setup on this side: the client above reaches this endpoint for every call it makes, and the model name on each call chooses the row of the catalogue that answers it. A script that already imports this package therefore needs no second dependency and no second account.
The library belongs to OpenAI and is maintained in its own repository. HeartFlowAI is not affiliated with it, does not redistribute it, and the argument names quoted here are documented there rather than here. They were checked at github.com/openai/openai-python.
One client, every model.
The model name travels
with each call.
A client constructed against this endpoint keeps working for every catalogue model, because the model is named per call rather than bound at construction.
The endpoints and the error codes are in the API reference, the credit side is on HFAI Cloud, and GPT-OSS 120B answers without credits.
The same key in every language.
The Python client, the JavaScript client and a plain HTTP call all take the endpoint and the key the same way, which is what makes the catalogue portable between them.