Como chamar vários modelos de imagem com uma única API Key

Por que as equipes buscam uma API unificada de geração de imagens

A geração de imagens geralmente começa com um único modelo. A equipe de produto testa um prompt, integra um SDK e entrega um protótipo pequeno. O problema surge depois: quando o produto precisa de mais de um estilo de saída — rascunhos rápidos para revisão interna, texto legível em pôsteres, renderização de texto em chinês para campanhas locais ou imagens fotorrealistas em páginas de produto.

Se cada modelo tem uma API key, uma estrutura de requisição, uma conta de cobrança e um padrão de callback diferentes, testar modelos se transforma em trabalho de infraestrutura. O padrão mais simples é manter a autenticação estável e mover a seleção de modelo para o corpo da requisição.

A página AI Image APIs da HiAPI é a principal página de comparação para esse fluxo de trabalho. Use-a para decidir qual modelo de imagem se encaixa no produto e consulte as páginas de cada modelo para obter os parâmetros e exemplos exatos.

Usar uma única API key no servidor

A API key deve ficar no backend, nunca no código do navegador. O frontend pode coletar prompts, imagens ou configurações de geração, mas o backend deve criar a tarefa na HiAPI.

Crie ou rotacione a key na página API Keys. Em produção, guarde-a em uma variável de ambiente do servidor e anexe-a como cabeçalho Authorization:

Authorization: Bearer YOUR_API_KEY

Assim você tem um único lugar para rotacionar credenciais, um único lugar para adicionar limites de taxa e uma superfície de cobrança para acompanhar à medida que o tráfego do fluxo de geração cresce.

Roteie pelo id do modelo, não pelo cliente do provedor

O detalhe de implementação fundamental é manter o endpoint estável e tratar o id do modelo como parâmetro de roteamento. Sua aplicação pode expor presets como "draft", "poster", "product image" ou "photorealistic", e o backend mapeia esses presets para ids de modelo.

Por exemplo, um produto pode começar com o Nano Banana para exploração rápida de ideias, usar o GPT Image 2 quando a imagem precisa de texto legível ou de prompts de reestruturação de layout, direcionar gráficos de redes sociais em chinês para o Qwen Image 2.0 e usar o FLUX 1.1 Pro para visuais de produto com acabamento comercial.

O código da aplicação não precisa de quatro fluxos de autenticação para dar suporte a isso. Ele só precisa de um caminho de criação de tarefa e uma pequena camada de roteamento.

Padrão mínimo de requisição

A seguir, uma requisição compacta que chama o GPT Image 2 por meio do endpoint unificado de tarefas:

curl -X POST https://api.hiapi.ai/v1/tasks \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gpt-image-2/text-to-image",
    "input": {
      "prompt": "A premium ecommerce hero image for a smart lamp, clean studio lighting",
      "aspect_ratio": "16:9",
      "resolution": "1K"
    }
  }'

Para os campos exatos do GPT Image 2, use a documentação da API do GPT Image 2. Para escolher um modelo, comece pela comparação de AI Image APIs.

Fluxo de produção com callbacks

O polling é conveniente para testes locais, mas o tráfego de produção geralmente se beneficia de callbacks. Quando o backend cria a tarefa, ele passa uma URL de callback e trata o callback como a fonte do estado final. Ainda é possível manter o polling de tarefas como fallback para reconciliação.

O fluxo prático é:

1. O frontend envia o prompt e as configurações de geração ao backend.
2. O backend valida a requisição, escolhe o id do modelo e cria a tarefa na HiAPI.
3. A HiAPI retorna o id da tarefa imediatamente.
4. O backend armazena o id da tarefa e aguarda o callback final.
5. Quando a tarefa atinge o estado final, a aplicação exibe a URL de saída.

Isso mantém a página voltada ao usuário responsiva e evita loops de polling agressivos que ficam barulhentos à medida que o volume de geração cresce.

Fluxo de preços sem preços fixos no código

Não copie tabelas de preços estáticas para o código da aplicação nem para documentação interna antiga. O fluxo mais seguro é direcionar usuários e operadores para a página de preços em tempo real e, em seguida, acompanhar o uso dentro do seu próprio produto.

Para geração de ícones sensível a custo, use modelos mais baratos enquanto os prompts ainda estão mudando. Aumente a resolução apenas depois que os prompts estiverem estáveis. Quando a saída precisar de texto mais nítido, layout mais rigoroso ou mais acabamento comercial, migre os materiais finais de marca ou produto para um modelo mais forte.

Esse padrão mantém a experimentação barata e ainda oferece ao produto um caminho final de alta qualidade.

Links internos que mantêm o caminho de SEO claro

Este artigo tem como objetivo apoiar a página central de APIs de imagem, não substituí-la. A página de comparação canônica é melhores APIs de geração de imagens com IA. A página de implementação específica do modelo é GPT Image 2 API. As páginas de conversão são GPT Image 2 na HiAPI, preços e API Keys.

Para fluxos de trabalho adjacentes, leia fluxo de trabalho de API de texto para vídeo vs imagem para vídeo e fatores de preço do GPT Image 2 e exemplos de produção.

Perguntas frequentes

Uma única API key pode chamar vários modelos de imagem?

Sim. Na HiAPI, a mesma API key pode criar tarefas para vários modelos de imagem. Basta alterar o id do modelo no corpo da requisição para rotear para modelos de imagem diferentes.

Devo expor a API key em uma aplicação de navegador?

Não. Mantenha a key no servidor. O código do navegador deve chamar o seu backend, e o backend cria a tarefa na HiAPI.

Com qual modelo de imagem devo começar?

Comece com o modelo que corresponde à tarefa. O Nano Banana é bom para ideação rápida, o GPT Image 2 é uma escolha padrão forte para prompts longos e texto legível, o Qwen Image 2.0 é adequado para renderização de texto em chinês e o FLUX 1.1 Pro é mais indicado para visuais de produto fotorrealistas.

Onde devo consultar os preços?

Use a página HiAPI Pricing para ver os preços atuais em tempo real. Evite copiar preços fixos para artigos ou código de produto, a menos que você tenha um processo de manutenção para atualizá-los.