Como Adicionar Staging Virtual ao Seu Aplicativo: Um Tutorial da API para Desenvolvedores

Adicionar staging virtual a um aplicativo se resume a um único loop: seu backend envia a foto de um cômodo para uma API de staging virtual como uma tarefa (job), o provedor a renderiza em segundo plano e seu aplicativo coleta o resultado, armazena-o ao lado do original e o exibe com a divulgação exigida pelo destino. Este tutorial constrói esse loop utilizando a Roomagen API, com código em cURL, Node.js e Python, mantendo o design portável para outros provedores.

A integração em resumo

1. Envie cada foto a partir do seu servidor como um job: POST /v1/jobs com uma Idempotency-Key.
2. Armazene o job_id retornado antes de fazer qualquer outra coisa.
3. Receba o job concluído em um webhook assinado e reconcilie falhas de entrega com GET /v1/jobs/{id}.
4. Hospede novamente o resultado em sua própria infraestrutura, mantenha o original ao lado dele e transporte os dados de divulgação para cada exportação.

O Que Você Está Construindo: Arquitetura de um Recurso de Staging

Ao final deste tutorial, seu aplicativo aceitará a foto de um ambiente e exibirá uma versão mobiliada do mesmo cômodo, normalmente de 20 a 60 segundos depois, de acordo com a documentação da Roomagen. Todo o restante aqui existe para tornar esse loop confiável em volume de produção. Esse mesmo loop atende portais de anúncios, plataformas de entrega de fotografias, softwares de gestão de propriedades que anunciam unidades desocupadas, aplicativos de design de interiores apresentando conceitos no próprio cômodo do cliente e lojas de móveis exibindo um ambiente decorado em um estilo escolhido.

Uma renderização leva dezenas de segundos — tempo demais para manter uma requisição HTTP aberta —, portanto, o design é assíncrono: envie o job, obtenha um ID de job imediatamente e colete o resultado mais tarde. O staging executa um pipeline de várias etapas (análise de cena, depois prompt e, em seguida, geração), sendo mais lento que ferramentas como a de dia para entardecer: nos dados de produção da Roomagen para o período de 30 dias até 1º de outubro de 2026, a mediana de um job de staging via API levou cerca de 45 segundos, contra cerca de 25 segundos para dia para entardecer e para planta baixa para 3D.

A Roomagen é uma plataforma de AI para edição de fotos e staging virtual com mais de 40 ferramentas em seu aplicativo web; a API documenta todas as ferramentas aceitas (65 em outubro de 2026) sob um único endpoint de jobs. Suas ferramentas de imagem são executadas nos modelos de imagem Gemini do Google, e a API adiciona o pipeline de staging, o gerenciamento de jobs, reembolsos automáticos para renderizações que falharem e webhooks assinados.

Antes de Começar: Chaves, Ambientes e Requisitos de Imagem

Obtendo uma chave. A API da Roomagen opera em modelo self-service desde seu lançamento público em 30 de agosto de 2026; não há fila de espera. Faça login no portal do desenvolvedor com uma conta Roomagen, confirme seu e-mail e crie uma chave, conforme descrito no início rápido da API. Sua primeira chave adiciona 50 imagens gratuitas, concedidas uma única vez por conta, o que é suficiente para construir e testar tudo neste guia. Até que a conta adquira um pacote, todas as renderizações incluem uma marca d'água da Roomagen; portanto, use-as para desenvolvimento e testes, não para publicação.

As chaves são compostas por rmg_live_ seguido de 64 caracteres hexadecimais, enviados no cabeçalho X-Api-Key, e o portal exibe cada chave apenas uma vez. Guarde-a em um gerenciador seguro de segredos no servidor; nunca a inclua em código JavaScript no navegador ou em um aplicativo móvel, onde qualquer pessoa possa extraí-la e consumir seu saldo.

Ambientes. Uma conta pode ter até 10 chaves ativas, permitindo que você crie uma por ambiente e revogue qualquer uma delas sem interferir na outra. Não há modo de teste: todas as chaves estão em ambiente de produção (live), e as chaves de uma conta compartilham um único saldo de imagens, um único webhook no portal e um único segredo de assinatura; portanto, defina uma webhook_url própria para cada job nos ambientes de desenvolvimento. Não há botão de rotação de chave, por projeto: crie a nova chave, faça o deploy e depois revogue a antiga.

Entradas de imagem.

Dê preferência a image_url: as requisições permanecem leves, você elimina o overhead de 33% do base64 e, como o download ocorre durante o processamento do seu POST, uma URL assinada só precisa ser válida pela duração dessa requisição. Envie a exportação em tamanho real, com um único cômodo por enquadramento, nivelada e com iluminação adequada; o modelo só consegue preservar os detalhes que puder visualizar.

Verifique o saldo via código. GET /v1/account retorna image_credits, a quantidade de imagens que seu saldo ainda pode renderizar. Configure um alerta de saldo baixo agora: quando o saldo não puder cobrir um job, POST /v1/jobs responderá com 402 insufficient_credits e nenhum job será criado.

Passo 1: Enviar um Job de Staging

Um único POST cria o job: a ferramenta, a imagem, as opções e, opcionalmente, uma webhook_url específica para o job (sem ela, a Roomagen utiliza o webhook da conta configurado no portal, ou você faz polling).

curl -X POST https://api.roomagen.com/api/v1/jobs \
  -H "X-Api-Key: $ROOMAGEN_API_KEY" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: photo-4821-3-stage" \
  -d '{
    "tool": "virtual-staging",
    "image_url": "https://cdn.example.com/rooms/4821-3.jpg",
    "options": { "style": "scandinavian", "roomType": "living-room", "mode": "empty-room" },
    "webhook_url": "https://app.example.com/hooks/roomagen"
  }'

A resposta retorna com status 201, antes da conclusão da renderização:

{ "job_id": "3f1c9d4e-5b2a-4c8e-9f10-7d6a2b3c4e5f", "status": "processing", "images_charged": 1 }

A mesma chamada a partir de um backend em Node.js 18+:

async function submitStagingJob(photo) {
  const res = await fetch("https://api.roomagen.com/api/v1/jobs", {
    method: "POST",
    headers: {
      "X-Api-Key": process.env.ROOMAGEN_API_KEY,
      "Content-Type": "application/json",
      "Idempotency-Key": `photo-${photo.id}-stage`, // derivado do seu registro, nunca aleatório
    },
    body: JSON.stringify({
      tool: "virtual-staging",
      image_url: photo.signedUrl,
      options: { style: photo.style, roomType: photo.roomType, mode: "empty-room" },
      webhook_url: "https://app.example.com/hooks/roomagen",
    }),
  });
  const body = await res.json();
  if (!res.ok) throw new Error(`${body.error.code}: ${body.error.message}`);
  await db.query(
    "INSERT INTO staging_jobs (photo_id, job_id, status, images_charged) VALUES ($1, $2, 'processing', $3)",
    [photo.id, body.job_id, body.images_charged],
  );
  return body.job_id;
}

O staging é mais rigoroso do que as outras ferramentas. O campo style é obrigatório, as opções usam camelCase e qualquer chave fora da lista abaixo — incluindo room_type, resolution, tier e customPrompt — é rejeitada com invalid_request. O staging sempre renderiza em 2K e consome uma imagem.

Os três modos correspondem aos modos de staging no aplicativo web da Roomagen, permitindo que sua equipe de produto os experimente antes de escrever código: Staging Virtual com AI para cômodos vazios, Redesenhe Ambientes Mobiliados para restyle e Reaproveitamento de Ambientes para recreate.

Persista antes de qualquer outra coisa. Salve o job_id e o images_charged vinculados ao seu próprio registro. O cabeçalho Idempotency-Key (de até 128 caracteres, com escopo para sua chave de API) torna as tentativas de repetição seguras: a mesma chave com o mesmo corpo de requisição retorna o job original, sem cobrança duplicada. Derive as chaves a partir de seus próprios registros para que você possa reconstruí-las após uma falha de sistema, e reenvie exatamente o mesmo corpo: a mesma chave com um corpo diferente, inclusive uma image_url reassinada, retorna 409 idempotency_conflict.

Passo 2: Tratar a Conclusão — Webhooks vs Polling

Existem duas maneiras de saber que um job terminou, e as integrações em produção utilizam ambas.

Use webhooks como canal principal e polling como rede de segurança. A documentação da Roomagen classifica os webhooks como "uma otimização, não um sistema de registro", pois uma entrega é abandonada assim que a janela de novas tentativas expira. O polling por si só também não escala: em um intervalo de 3 segundos, cada job gera 20 requisições por minuto, de modo que o limite de 300 requisições por minuto em GET /v1/jobs/{id} suporta cerca de 15 jobs em polling simultâneo.

Configure o endpoint. Salve um endpoint https no card de Webhook do portal, informando a URL final, pois redirecionamentos não são seguidos. Armazene o segredo de assinatura whsec_ como uma senha e dispare um envio de job.test com o botão Send test event enquanto valida a verificação. Uma webhook_url definida por job utiliza o mesmo segredo.

const crypto = require("crypto");
const express = require("express");
const app = express();

// Raw body on this route, mounted before any global express.json()
app.post("/hooks/roomagen", express.raw({ type: "application/json" }), async (req, res) => {
  const ts = req.get("X-Roomagen-Timestamp");
  const sig = req.get("X-Roomagen-Signature");
  if (!ts || !sig) return res.sendStatus(401);

  const expected = "v1=" + crypto
    .createHmac("sha256", process.env.ROOMAGEN_WEBHOOK_SECRET) // whsec_...
    .update(`${ts}.`)
    .update(req.body) // the raw bytes, never re-serialized JSON
    .digest("hex");
  const fresh = Math.abs(Date.now() / 1000 - Number(ts)) < 300;
  if (sig.length !== expected.length || !fresh ||
      !crypto.timingSafeEqual(Buffer.from(sig), Buffer.from(expected))) {
    return res.sendStatus(401);
  }

  const job = JSON.parse(req.body);
  if (job.event === "job.test") return res.sendStatus(200);

  // Idempotent: only the first delivery (or poll) moves the row out of "processing"
  const { rowCount } = await db.query(
    "UPDATE staging_jobs SET status = $1, result_urls = $2, error = $3 WHERE job_id = $4 AND status = 'processing'",
    [job.status, job.result_urls, job.error, job.job_id],
  );
  if (rowCount === 1 && job.status === "completed") {
    await queue.add("store-results", { jobId: job.job_id }); // download off the request path
  }
  res.sendStatus(200);
});

Quatro detalhes fundamentais:

1. Verifique sobre os bytes brutos. O cabeçalho é composto por v1= seguido pelo HMAC-SHA256 hexadecimal de {X-Roomagen-Timestamp}.{raw body}; um JSON resserializado não será compatível.
2. Compare em tempo constante e, em seguida, verifique o frescor da mensagem. O método timingSafeEqual do Node lança erro se os tamanhos forem diferentes, portanto compare os comprimentos antes. Rejeitar registros de data/hora (timestamps) com mais de cerca de cinco minutos impede ataques de repetição, a mesma estratégia descrita na documentação de webhooks da Stripe; mantenha os relógios dos servidores sincronizados.
3. Responda rápido. A Roomagen aguarda 10 segundos por uma resposta 2xx; qualquer outra coisa, incluindo tempo limite esgotado, é tratada como tentativa com falha e entra na fila de reenvio.
4. Seja idempotente. A entrega ocorre no modelo at-least-once e fora de ordem, e seu serviço de polling pode já ter concluído o processamento do job; portanto, desduplique utilizando o job_id.

Para o polling, durante o desenvolvimento ou como mecanismo de reconciliação, a versão em Python é concisa:

import os, time, requests

API = "https://api.roomagen.com/api/v1"
HEADERS = {"X-Api-Key": os.environ["ROOMAGEN_API_KEY"]}

def wait_for_job(job_id, interval=3, max_wait=300):
    deadline = time.time() + max_wait
    while time.time() < deadline:
        r = requests.get(f"{API}/jobs/{job_id}", headers=HEADERS, timeout=30)
        r.raise_for_status()
        job = r.json()
        if job["status"] != "processing":
            return job  # "completed" or "failed"; both are final
        time.sleep(interval)
    return None  # still processing: leave it to the reconciler

Um job finaliza como completed, com result_urls, ou como failed, com o motivo indicado em error e um estorno automático; registre processing_ms para monitorar a latência. Execute um reconciliador a cada um ou dois minutos para jobs que permaneçam em processing após alguns minutos. Não marque um job lento como com falha apenas pelo término de um temporizador: ele ainda pode ser concluído e já foi cobrado no momento da criação.

Passo 3: Entregar os Resultados aos Seus Usuários

Um job concluído retorna result_urls, uma lista de imagens JPEG renderizadas. Não faça hotlink dessas URLs.

Hospede novamente os resultados. A Roomagen fornece os resultados a partir de seu próprio armazenamento, sujeita à retenção da conta; portanto, um job em segundo plano deve baixar cada imagem assim que o job for concluído, gravá-la em seu próprio bucket (S3, R2, GCS ou similar) e servi-la a partir da sua CDN. Dessa forma, suas imagens nunca dependerão da política de retenção de um fornecedor.

Mantenha o original ao lado do resultado. Armazene a foto original e a imagem com staging como um par vinculado. Esse par viabiliza um controle deslizante de antes/depois, permite que os usuários revertam alterações e atende ao que as regras de divulgação de anúncios exigem (Passo 4).

Esteja preparado para variações. O resultado de modelos generativos varia, e ocasionalmente o sofá pode não agradar. Uma nova execução é um novo job que consome outra imagem, pois a Roomagen estorna apenas renderizações que falham tecnicamente, e não resultados dos quais o usuário não gostou. Atribua a cada reexecução sua própria Idempotency-Key, como photo-4821-stage-2: reutilizar a primeira chave retorna o job original, ou um erro 409 caso o corpo da requisição tenha sido alterado. Disponibilize um botão "Tentar novamente" e decida se esse custo será repassado de forma visível aos usuários ou absorvido em sua estrutura de preços.

Projete os estados de espera e de falha. O staging normalmente leva até um minuto para ser processado, o que representa uma espera considerável em termos de interface. Desenvolva o estado de progresso, o estado de falha ("a renderização falhou e o valor foi estornado") e a ação de tentar novamente antes de lançar a funcionalidade.

Passo 4: Inclua a Divulgação no Seu Modelo de Dados

Se seus usuários inserirem fotos com staging em anúncios de imóveis, a divulgação é uma obrigação legal deles, e seu modelo de dados determinará se cumprir essa obrigação será simples. A API da Roomagen não adiciona rótulo de divulgação nem vinculação entre original e editada, e os termos da Roomagen estabelecem que a divulgação é de responsabilidade do usuário; portanto, sua integração deve gerenciá-la.

• California AB 723, em vigor desde 1º de janeiro de 2026. Um corretor responsável ou vendedor, ou qualquer pessoa agindo em nome deles, que utilize uma imagem alterada digitalmente no anúncio de venda de um imóvel deve declarar, sobre a imagem ou junto a ela, que a imagem foi alterada, e adicionar um link, URL ou QR code para uma página pública que exiba a imagem original, sem alterações. O órgão regulador do setor imobiliário da Califórnia acrescenta que, quando uma ferramenta de AI gera publicidade enganosa, a responsabilidade recai "sobre o titular da licença e seu corretor responsável, e não sobre o provedor da tecnologia."
• Anúncios de locação na Califórnia a partir de 1º de janeiro de 2027. O projeto AB 2025 estende exigências semelhantes de divulgação à publicidade de locações, abrangendo locadores e outros agentes, e não apenas profissionais licenciados.
• As regras dos MLS divergem quanto ao posicionamento. O Canopy MLS exige o rótulo diretamente sobre a imagem, e não apenas nas legendas, enquanto o NWMLS não aceita fotos contendo gráficos ou textos sobrepostos.
• Produtos voltados à União Europeia. Desde 2 de agosto de 2026, o Artigo 50 do EU AI Act exige que os responsáveis pela implantação de sistemas de AI que gerem ou manipulem imagens do tipo "deep fake" (conteúdo que se assemelhe a locais ou objetos reais e que possa parecer falsamente autêntico) façam a divulgação dessa alteração — uma definição na qual fotos de o imóvel em si editadas por AI podem perfeitamente se enquadrar (veja nosso guia sobre o Artigo 50 do EU AI Act).

Portanto, armazene a divulgação como dados, e não como pixels: uma URL pública para a foto original, uma flag altered com a ferramenta e as opções utilizadas, além do texto de divulgação e o posicionamento do rótulo para cada plataforma de destino. Renderize o rótulo no momento da exportação, e não ao salvar no banco.

Este conteúdo é um resumo para desenvolvedores, não constituindo consultoria jurídica; nosso guia sobre a AB 723 e regras de fotos de AI em MLS e nosso guia de requisitos de fotos em MLS e divulgação de staging virtual aprofundam o tema.

Aspectos de Produção: Limites de Taxa, Tentativas e Gestão de Créditos

Limites de taxa (rate limits). Calculados por chave, em uma janela deslizante de 60 segundos: 60 requisições por minuto para POST /v1/jobs, 300 para GET /v1/jobs/{id} e 120 para GET /v1/tools e GET /v1/account, além de 600 por minuto por IP de cliente, compartilhado entre todos os servidores atrás de um mesmo endereço NAT. Respostas bem-sucedidas incluem os cabeçalhos X-RateLimit-Limit e X-RateLimit-Remaining; o status 429 rate_limited inclui o cabeçalho Retry-After em segundos, portanto respeite esse valor em vez de criar um mecanismo próprio de backoff. Para operações em grande escala, enfileire os envios: a 60 jobs por minuto, 500 fotos levam pouco mais de oito minutos para serem submetidas.

Novas tentativas e códigos de erro. Todos os erros seguem o formato { "error": { "code", "message", "doc_url" } }. Trate as condições com base em code, nunca em message:

Impacto financeiro de falhas. Um job que falhar durante a geração tem o valor estornado automaticamente, mas o campo images_charged no registro do job não é reescrito; portanto, considere o endpoint GET /v1/account como a fonte definitiva para seu saldo. Ao comparar fornecedores, avalie as políticas de falha lado a lado com os preços.

Gestão de créditos. A Roomagen cobra o uso da API por imagens, adquiridas previamente em pacotes pelo portal do desenvolvedor:

Os pacotes nunca expiram e seus créditos são cumulativos. Cada ferramenta documentada custa uma imagem por renderização em 2K; a opção resolution: "4K" dobra esse custo nas ferramentas que a suportam, e o staging sempre custa uma imagem. Para calcular seu orçamento, considere as repetições: uma plataforma que realiza o staging de 1.200 fotos por mês e prevê que uma a cada dez precise ser refeita precisará de cerca de 1.320 imagens, fazendo com que um pacote Growth dure quase dois meses.

Os valores de mercado variam bastante (levantamento de outubro de 2026): ModelsLab indica $0,02 por renderização de interiores, Decor8 cobra $0,20 por imagem para todas as operações de API, e AI HomeDesign cobra $0,24 por foto no plano anual ou cerca de $0,49 na cobrança mensal. Compare a variedade de ferramentas, suporte a webhooks, política de falhas e qualidade visual, além do preço unitário; nosso guia de preços de APIs de staging virtual e nosso comparativo de APIs de staging analisam fornecedor por fornecedor.

Uma ressalva sincera sobre maturidade. A API da Roomagen é recente: a versão 1 foi lançada em 30 de agosto de 2026 com um único endpoint para jobs, e sua documentação passou a abranger todas as ferramentas aceitas apenas a partir de 3 de outubro de 2026; portanto, ela adota convenções modernas, mas ainda não possui anos de histórico público. Mudanças que quebram compatibilidade (breaking changes) são comunicadas por e-mail às contas com chaves ativas antes de irem ao ar; melhorias aditivas podem ser lançadas a qualquer momento, portanto ignore campos desconhecidos nas respostas.

Expandindo a Integração: Outras Ferramentas Documentadas

Depois que o loop estiver funcionando para staging, adicionar um botão de "versão crepúsculo" ou "remover objetos" exige alterar apenas os parâmetros tool e options:

Essas ferramentas também aceitam resolution (2K ou 4K), tier (auto, guided ou custom) e customPrompt (até 500 caracteres). Diferentemente do staging, elas ignoram chaves desconhecidas — listando cada uma delas no campo warnings da resposta —, mas ainda rejeitam valores fora do intervalo permitido. Para cômodos sem janelas, defina hasWindows: false na ferramenta de dia para entardecer para que o prompt desconsidere instruções sobre janelas e vistas externas.

A rota GET /v1/tools retorna todos os slugs que sua chave pode acionar, com seus respectivos custos em imagens, e todos os slugs listados estão documentados. Consulte a lista programaticamente em vez de fixá-la no código, e lembre-se de que os nomes de ferramentas em roomagen.com não correspondem aos slugs da API.

O Que a API Não Faz

• Sem endpoint de lote. Um job processa uma imagem em uma ferramenta; o Processamento em lote do aplicativo web não faz parte da API, portanto enfileire os jobs respeitando os limites de taxa.
• Sem rótulos de divulgação. As imagens geradas não possuem rótulo de divulgação nem a composição de antes/depois. As renderizações trazem marca d'água até que a conta compre um pacote, e deixam de exibir qualquer marca da Roomagen a partir de então.
• Sem regeneração gratuita. Uma reexecução é um novo job e é faturada normalmente.
• Sem medições ou arquivos CAD. Os arquivos de saída são imagens JPEG, e não dimensões, vetores ou arquivos DWG. Se você precisa extrair medidas de ambientes a partir de fotos, uma API de imagem generativa não é a ferramenta indicada.
• Sem garantia absoluta de saída. Modelos generativos podem introduzir artefatos ou inconsistências visuais, portanto revise o resultado antes de incluí-lo em um anúncio.
• Sem recursos exclusivos da interface web. Recursos como Refinar, a Biblioteca e o chat Design Companion são exclusivos do aplicativo web da Roomagen.

Erros Comuns em Integrações com APIs de Staging

1. Bloquear a thread de requisição. Manter a requisição do usuário aberta enquanto o job é renderizado provoca estouro de tempo limite (timeout) nos balanceadores de carga. Retorne 202 Accepted a partir da sua própria API e envie atualizações para o cliente.
2. Nomes de opções incorretos. Enviar room_type ou resolution em um job de staging retorna invalid_request; o staging requer chaves em camelCase da sua própria lista, exigindo sempre o parâmetro style.
3. Confiar apenas em webhooks. Após cerca de 36 minutos de tentativas sucessivas, a Roomagen interrompe os envios. Sem um reconciliador, o job permanecerá em "processing" indefinidamente.
4. Verificar a assinatura de forma incorreta. Calcular o hash sobre o JSON parseado, omitir o prefixo com o timestamp, fazer comparações com === ou deixar de checar se o timestamp é recente comprometem a integridade da verificação.
5. URL de webhook com redirecionamento. Protocolo http comum e hosts privados são rejeitados de imediato com webhook_url_rejected, e redirecionamentos não são seguidos, de modo que uma barra final ausente ou redirecionamento www fará todas as entregas falharem.
6. Chaves de idempotência aleatórias ou URLs reassinadas. Uma chave não armazenada não pode ser reutilizada, fazendo com que a nova tentativa gere uma nova cobrança; reenviar a mesma chave com uma image_url reassinada retorna 409.
7. Fazer hotlink das URLs de resultado. Os resultados estão sujeitos às regras de retenção do provedor. Transfira e hospede os arquivos em sua própria infraestrutura assim que a tarefa terminar.
8. Utilizar uma mesma marca d'água para todos os destinos. Um rótulo "Virtually Staged" gravado na imagem pode violar as regras de os MLS contra textos sobrepostos e, sem um link para a foto original, não atende integralmente às exigências da AB 723.

Checklist Pré-Lançamento

• A chave de API reside exclusivamente em seus servidores, com uma chave para cada ambiente.
• As requisições de staging sempre enviam style e nenhum parâmetro além da lista de opções permitidas para staging.
• Todo job possui uma Idempotency-Key derivada dos seus registros internos, e as novas tentativas reenviam exatamente o corpo original.
• O endpoint de webhook é a URL https final, valida assinaturas v1= sobre o corpo bruto, rejeita timestamps antigos e responde em menos de 10 segundos.
• Uma entrega de evento job.test enviada pelo portal passa com sucesso na validação.
• Um processo de reconciliação verifica jobs que continuam com status de processamento após alguns minutos.
• Os resultados são baixados e hospedados na sua própria infraestrutura, cada um armazenado ao lado de sua foto original.
• Os dados de divulgação (URL da foto original, flag de alteração, rótulo específico por destino) são transmitidos em todos os fluxos de exportação.
• Um alerta de saldo baixo monitora o campo image_credits, e todos os códigos de erro estão mapeados para mensagens compreensíveis aos seus usuários.

Conclusão: Lance o Loop e Depois Expanda

Adicionar staging virtual a um aplicativo é uma integração enxuta: uma chamada POST com chave de idempotência, um manipulador de webhook verificado apoiado por um reconciliador e uma rotina de armazenamento que salva o arquivo original ao lado do resultado gerado. O fluxo principal é implementado em poucas dezenas de linhas de código; a maior parte do esforço reside na robustez para produção e na estruturação dos dados de divulgação. Nada disso fica amarrado a um único fornecedor: envio assíncrono, confirmação via push associada a pull, armazenamento próprio dos resultados e vinculação entre imagem original e editada são padrões que funcionam com qualquer API de staging.

Para começar a desenvolver com base no exemplo prático apresentado, obtenha uma chave de API da Roomagen: a primeira chave inclui 50 imagens gratuitas, e o guia de início rápido, o guia de webhooks e a referência de erros detalham todas as especificações. Esse mesmo fluxo de jobs permite operar recursos de staging virtual, dia para entardecer, remoção de itens, melhoria de fotos, reforma virtual e planta baixa para 3D a partir de uma única integração.