HiAPI
Blog

Tutorial

So verwendest du ideogram-v4.5 über die HiAPI API: curl, Python und eine funktionierende Anfrage

Oct 31, 2026
封面图:浅灰蓝底上多层半透明玻璃片交叠,折射出克制的蓝色条带,安静而具建筑感。

Was ideogram-v4.5 auf HiAPI für dich leistet

Wenn der Text im Bild wirklich wichtig ist, ist ideogram-v4.5 das Modell der Wahl. Posterlayouts, Logografiken, Verpackungs-Mockups, Social Cards – überall dort, wo eine falsch geschriebene Überschrift oder eine verwaschene Beschriftung das Material ruiniert, liegt der Wert dieses Modells. Wenn du abstrakte Texturen oder fotografische Landschaften erzeugen willst, in denen nichts klar lesbar sein muss, sind Allzweck-Bildmodelle in der Regel günstiger und schneller.

Dieser Artikel ist eine Integrationsanleitung, kein Modellvergleich. Nach der Lektüre hast du eine lauffähige Anfrage, einen Python-Client, der dasselbe tut, und eine wiederverwendbare Hilfsfunktion, die die Teile übernimmt, bei denen typischerweise Fehler passieren: der Seitenverhältnis-Parameter, das Polling asynchroner Aufgaben und das Abrufen der Ausgabe.

Eines solltest du dir früh einprägen: Die Bildgenerierung auf HiAPI ist eine asynchrone Task-API. Du übermittelst eine Anfrage, erhältst eine Kennung und pollst dann, bis die Aufgabe abgeschlossen ist. Code, der davon ausgeht, dass der Antwortkörper bereits das Bild enthält, funktioniert nicht. Jeder Abschnitt unten arbeitet auf dieses Muster hin.

Bevor du die Anfrage sendest

Vor dem ersten Aufruf brauchst du vier Dinge.

1. API-Schlüssel

Erstelle einen in deiner HiAPI-Kontokonsole und halte ihn von der Versionsverwaltung fern. Exportiere ihn als Umgebungsvariable, statt ihn ins Skript zu kopieren:

export HIAPI_API_KEY="your_key_here"

2. Basis-URL

Alle Anfragen gehen an die HiAPI-API-Basis-URL, ergänzt um den konkreten Pfad des Generierungsendpunkts. Die Plattformdokumentation listet den aktuellen Pfad auf; wenn die Dokumentation etwas anderes sagt, hardcode nicht den Pfad, den du in einem Blogbeitrag (einschließlich diesem) gesehen hast.

3. Modellbezeichner

Der Modell-String, den du im Anfragekörper übergibst, identifiziert ideogram-v4.5. Verwende die exakte Schreibweise inklusive Groß-/Kleinschreibung aus der Modellliste der Plattform – Modellbezeichner werden wörtlich abgeglichen, und eine kleine Abweichung führt zu einem Validierungsfehler statt zu einem hilfreichen Hinweis.

4. Parameterreferenz

Die Modellseite von ideogram-v4.5 ist die maßgebliche Quelle dafür, welche Felder der Anfragekörper akzeptiert: Prompt-Längenlimits, unterstützte Seitenverhältnisse, Ausgabeformate sowie etwaige Seed- oder Stilsteuerungen. Lies sie, bevor du Code schreibst. Parameter, die dort nicht aufgeführt sind, werden möglicherweise stillschweigend ignoriert oder abgelehnt, und das Raten von Werten ist der häufigste Grund für verschwendete Debugging-Zeit.

Mit diesen vier Dingen kannst du deine erste Anfrage senden.

Eine funktionierende curl-Anfrage

Hier ist ein minimales Übermittlungsbeispiel. Wenn dein Konto andere Werte anzeigt, ersetze den Endpunktpfad und den Modellbezeichner durch die aus der Plattformdokumentation.

curl -X POST "$HIAPI_BASE_URL/<generation-path>" \
  -H "Authorization: Bearer $HIAPI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "ideogram-v4.5",
    "input": {
      "prompt": "A vintage travel poster for the Amalfi Coast, bold serif headline reading \"AMALFI\", warm sunset palette, grainy print texture"
    }
  }'

Was die einzelnen Teile bewirken:

  • Authorization — Bearer-Token-Authentifizierung. Ein fehlender oder falsch formatierter Header ist die häufigste Ursache für 401.
  • Content-Type — muss application/json sein. Manche HTTP-Clients setzen ihn bei POST nicht automatisch, was zu verwirrenden Parsing-Fehlern auf Serverseite führt.
  • model — der wörtliche Modellbezeichner. Platziere ihn wie dokumentiert auf der obersten Ebene des Anfragekörpers.
  • input.prompt — deine Generierungsanweisung. Setze den Text, den du im Bild gerendert haben willst, wie oben gezeigt in Anführungszeichen, damit das Modell ihn als wörtlichen Text und nicht als Beschreibung behandelt.
  • input.* — alle anderen Generierungsparameter (Seitenverhältnis, Format, Seed usw.) gehören in dieses verschachtelte Objekt, neben prompt.

Nach erfolgreicher Übermittlung wird ein JSON-Objekt zurückgegeben, das die Aufgabenkennung und ein Statusfeld enthält. In dieser Antwort ist kein Bild enthalten – das ist erwartetes Verhalten. Speichere die Kennung; der Polling-Schritt benötigt sie.

Denselben Aufruf mit Python senden

Die Python-Version ist eine Eins-zu-eins-Übersetzung. Wir verwenden requests und teilen denselben Anfragekörper, damit du beide bequem nebeneinander vergleichen kannst.

import os
import json
import requests

API_KEY = os.environ["HIAPI_API_KEY"]
BASE_URL = os.environ["HIAPI_BASE_URL"]
GEN_PATH = "/<generation-path>"  # confirm in platform docs

payload = {
    "model": "ideogram-v4.5",
    "input": {
        "prompt": (
            "A vintage travel poster for the Amalfi Coast, bold serif "
            'headline reading "AMALFI", warm sunset palette, grainy print texture'
        )
    },
}

response = requests.post(
    BASE_URL + GEN_PATH,
    headers={
        "Authorization": f"Bearer {API_KEY}",
        "Content-Type": "application/json",
    },
    data=json.dumps(payload),
    timeout=30,
)
response.raise_for_status()

job = response.json()
print(job)

Zwei bewusste Entscheidungen:

  • json.dumps statt json= hält das Übertragungsformat sichtbar konsistent mit dem curl-Beispiel. Beides funktioniert; die explizite Schreibweise erleichtert es, beim Debuggen zu prüfen, was du tatsächlich sendest.
  • timeout=30 gilt nur für die Übermittlung. Die Übermittlung ist schnell, die Generierung nicht. Lass den Übermittlungsaufruf niemals ein kurzes Timeout erben, das für das Polling gedacht ist, sonst meldest du einen normal laufenden Task als Fehler.

Das ausgegebene job-Dictionary enthält die Aufgabenkennung und den aktuellen Status. Speichere die Kennung irgendwo – die Polling-Schleife ist darauf angewiesen.

Seitenverhältnis und Ausgabeformat steuern

Seitenverhältnis und Ausgabeformat sind Parameter des Anfragekörpers, keine separaten Endpunkte. Sie befinden sich im selben input-Objekt wie der Prompt:

{
  "model": "ideogram-v4.5",
  "input": {
    "prompt": "...",
    "aspect_ratio": "<ratio from docs>",
    "output_format": "<format from docs>"
  }
}

Die hier wichtige Disziplin lautet: Werte nicht raten. Jedes Generierungsmodell bietet feste Aufzählungen von Verhältnissen und Formaten, und verschiedene Modelle akzeptieren unterschiedliche Schreibweisen – 16:9 versus 16x9, png versus PNG und so weiter. Das Übergeben eines vom Modell nicht unterstützten Werts führt in der Regel zu einem Validierungsfehler oder, schlimmer, zu einem stillen Rückfall auf die Standardausgabe, was wie ein Bug in deinem Prompt aussieht.

Der Workflow ist also:

  1. Öffne die Modellseite von ideogram-v4.5 auf der Plattform und kopiere die Liste der unterstützten Seitenverhältnisse und Ausgabeformate wortwörtlich.
  2. Lege diese Werte in eine kleine Whitelist im Code, damit ungültige Eingaben schon an der Aufrufstelle fehlschlagen, nicht erst bei der API.
  3. Verwende standardmäßig ein Verhältnis, das zu deinem nachgelagerten Layout passt. Wenn das Bild in einen Social-Card-Platz von 1200×630 passt, wähle einen Wert nahe diesem Verhältnis, statt ein Quadrat zu erzeugen und dann Inhalte abzuschneiden.

Textlastige Bilder verdienen einen zusätzlichen Hinweis: Extreme Verhältnisse (ultrabreite Banner, sehr hohe Poster) verringern den Raum, der für das Rendern von Text zur Verfügung steht. Für Überschriften, die wirklich klar lesbar sein müssen, sind mittlere Quer- oder Hochformate sicherer als panoramische Extremverhältnisse.

Asynchrone Aufgaben verarbeiten und Ergebnisse herunterladen

Der Lebenszyklus einer Generierung hat drei Schritte: Übermitteln → Pollen → Abrufen.

Übermitteln

Diesen Schritt hast du in den vorherigen Abschnitten bewältigt. Die Antwort liefert dir eine Aufgabenkennung und einen Status, etwa queued oder processing.

Pollen

Frage mit dieser Kennung den Statusendpunkt der Aufgabe ab, bis der Status die Fertigstellung meldet. Zwei Regeln halten diesen Prozess ordentlich:

  • Zwischen den Abfragen schlafen. Beginne bei etwa einer Sekunde und erhöhe schrittweise (Backoff). Den Statusendpunkt zu bombardieren macht die Aufgabe nicht schneller fertig und riskiert Rate-Limiting.
  • Wartezeit begrenzen. Lege eine maximale Anzahl Versuche oder eine Frist fest und melde bei Überschreitung einen klaren Fehler, statt in einer Endlosschleife zu hängen.
import time

def wait_for_job(job_id, headers, base_url, status_path,
                 max_attempts=60, initial_delay=1.0, factor=1.5):
    delay = initial_delay
    for _ in range(max_attempts):
        r = requests.get(
            f"{base_url}{status_path}/{job_id}",
            headers=headers,
            timeout=30,
        )
        r.raise_for_status()
        data = r.json()
        status = data.get("status")
        if status in ("succeeded", "completed", "success"):
            return data
        if status in ("failed", "error", "cancelled"):
            raise RuntimeError(f"job {job_id} ended with status {status}: {data}")
        time.sleep(delay)
        delay *= factor
    raise TimeoutError(f"job {job_id} did not finish in time")

Schlage in der Plattformdokumentation die exakten Status-Strings und den Statuspfad für dein Konto nach – gleiche gegen die Werte in der Dokumentation ab und behandle jeden nicht erkannten Status so, als würde er noch laufen, nicht als Erfolg.

Abrufen

Wenn die Aufgabe die Fertigstellung meldet, enthält die Antwort den Ausgabeort (in der Regel eine URL). Lade ihn mit einem normalen GET herunter und schreibe die Bytes auf die Festplatte. Ausgabe-URLs können zeitlich begrenzt sein, also lade zeitnah herunter, statt die URL für später zu speichern. Alles, was du zum Schreiben dieser Schleife wissen musst, ergibt sich aus der Struktur der Übermittlungsantwort – es gibt keine separate „Bild abrufen“-API zu lernen.

In eine wiederverwendbare Hilfsfunktion verpacken

Drei Inline-Skripte, die jeweils das Polling neu implementieren, sind ein Wartungsproblem. Packe es einmal ein.

import os, json, time, requests

class IdeogramClient:
    def __init__(self, base_url, api_key, gen_path, status_path,
                 poll_attempts=60, poll_factor=1.5):
        self.base_url = base_url.rstrip("/")
        self.gen_path = gen_path
        self.status_path = status_path
        self.poll_attempts = poll_attempts
        self.poll_factor = poll_factor
        self.headers = {
            "Authorization": f"Bearer {api_key}",
            "Content-Type": "application/json",
        }

    def generate(self, prompt, **params):
        body = {"model": "ideogram-v4.5", "input": {"prompt": prompt, **params}}
        r = requests.post(self.base_url + self.gen_path,
                          headers=self.headers,
                          data=json.dumps(body), timeout=30)
        r.raise_for_status()
        job = r.json()
        done = self._wait(job["id"])
        url = done["output"]["url"]  # confirm shape in docs
        return self._download(url)

    def _wait(self, job_id):
        delay = 1.0
        for _ in range(self.poll_attempts):
            r = requests.get(f"{self.base_url}{self.status_path}/{job_id}",
                             headers=self.headers, timeout=30)
            r.raise_for_status()
            data = r.json()
            if data.get("status") in ("succeeded", "completed", "success"):
                return data
            if data.get("status") in ("failed", "error", "cancelled"):
                raise RuntimeError(data)
            time.sleep(delay)
            delay *= self.poll_factor
        raise TimeoutError(job_id)

    def _download(self, url):
        r = requests.get(url, timeout=60)
        r.raise_for_status()
        return r.content

Die Verwendung ist ein einziger Aufruf: img_bytes = IdeogramClient(...).generate("...", aspect_ratio="<from docs>"). Passe den Zugriff auf done["output"]["url"] und die Status-Strings an die dokumentierte Antwortstruktur an – diese beiden Stellen müssen am ehesten kontospezifisch feinjustiert werden.

Häufige Fehler und Debugging-Tipps

Die meisten Fehlschläge in der ersten Woche fallen in fünf Kategorien.

401 / 403 — Authentifizierung. Schlüssel fehlt, enthält durch Copy-and-Paste Whitespace oder es fehlt das Präfix Bearer . Gib die ersten und letzten vier Zeichen des Schlüssels aus, den du tatsächlich sendest; ein Zeilenumbruch am Ende aus einer Env-Datei ist der klassische Übeltäter.

400 — fehlerhaftes JSON oder unbekannte Felder. Wenn der Anfragekörper durch String-Verkettung zusammengesetzt wurde, zerstören nicht maskierte Anführungszeichen im Prompt das JSON. Baue den Anfragekörper als Dictionary und serialisiere ihn mit json.dumps. Wenn das JSON sich parsen lässt, ist der nächste Verdächtige ein vom Modell nicht akzeptierter Parametername – prüfe deine Schlüssel Zeichen für Zeichen gegen die Modellseite.

404 / Modell nicht gefunden. Meist ist der Modellbezeichner falsch geschrieben oder in falscher Groß-/Kleinschreibung, oder der Endpunktpfad ist veraltet. Kopiere beides aus der Plattformdokumentation, nicht aus dem Gedächtnis oder aus einem alten Tutorial.

429 — Rate-Limiting. Fast immer wegen zu aggressivem Polling. Erhöhe die anfängliche Polling-Verzögerung und den Backoff-Faktor. Auf der Übermittlungsseite füge für 429- und 5xx-Antworten Wiederholungen mit Jitter hinzu, aber wiederhole keine 4xx-Validierungsfehler – die schlagen jedes Mal auf dieselbe Weise fehl.

Aufgabe erfolgreich, aber das Bild lässt sich nicht öffnen. Prüfe, ob du Bytes herunterlädst und nicht eine JSON-Fehlerseite; ein raise_for_status() beim Download-GET fängt die meisten dieser Fälle ab. Stelle außerdem sicher, dass du die Download-URL als kurzlebig behandelst und sie nicht sitzungsübergreifend cachest.

Im Zweifel protokolliere den vollständigen Antwortkörper und den Statuscode jedes Aufrufs in der gesamten Aufrufkette – Übermittlung, jede Polling-Abfrage und den Download. Die API sagt dir normalerweise klar, wo es schiefgelaufen ist; der Bug ist meistens, dass wir nie nachgesehen haben.

Mit einer funktionierenden Übermittlung, einer Polling-Schleife und einer vernünftigen Fehlerbehandlung lässt sich ideogram-v4.5 wie jeder andere HiAPI-Modellaufruf in eine echte Pipeline einbinden.

Ähnliche Artikel

Alle Artikel ansehen →

Starte mit persistenten KI-Artefakten

Hol dir deinen API-Key und rufe Bild-, Video- und Audiomodelle über eine einzige task-basierte API auf.

API-Dokumentation lesen