Comment ajouter le home staging virtuel à votre application : tutoriel API pour développeurs

Ajouter le home staging virtuel à une application se résume à une seule boucle : votre backend envoie la photo d'une pièce à une API de home staging virtuel sous forme de tâche (job), le fournisseur effectue le rendu en arrière-plan, et votre application récupère le résultat, le stocke aux côtés de l'original et l'affiche avec la divulgation requise par la destination. Ce tutoriel met en place cette boucle avec l'API Roomagen, avec des exemples de code en cURL, Node.js et Python, tout en conservant une conception portable vers d'autres fournisseurs.

L'intégration en un coup d'œil

1. Envoyez chaque photo depuis votre serveur sous forme de tâche : POST /v1/jobs avec un en-tête Idempotency-Key.
2. Stockez le job_id renvoyé avant de faire quoi que ce soit d'autre.
3. Recevez la tâche terminée via un webhook signé, et réconciliez les échecs avec GET /v1/jobs/{id}.
4. Réhébergez le résultat, conservez l'original à ses côtés et transmettez les données de divulgation à chaque export.

Ce que vous construisez : architecture d'une fonctionnalité de staging

À la fin de ce tutoriel, votre application acceptera la photo d'une pièce et affichera une version meublée de cette même pièce, généralement 20 à 60 secondes plus tard selon la documentation de Roomagen. Tout le reste sert à rendre cette boucle fiable à des volumes de production. La même boucle dessert les portails d'annonces, les plateformes de livraison de photos, les logiciels de gestion immobilière faisant la promotion de logements vacants, les applications de design d'intérieur présentant un concept sur la pièce réelle d'un client, et les détaillants de meubles montrant une pièce décorée selon un style choisi.

Un rendu prend des dizaines de secondes, ce qui est bien trop long pour maintenir une requête HTTP ouverte. La conception est donc asynchrone : soumettez la tâche, obtenez immédiatement un identifiant de tâche, puis récupérez le résultat plus tard. Le staging exécute un pipeline en plusieurs étapes (analyse de la scène, puis prompt, puis génération) ; il est donc plus lent que des outils comme la retouche jour en crépuscule : dans les données de production de Roomagen pour les 30 jours précédant le 1er octobre 2026, la tâche médiane de staging par API a pris environ 45 secondes, contre environ 25 secondes pour la retouche jour en crépuscule et pour le plan d'étage en 3D.

Roomagen est une plateforme de retouche photo par IA et de home staging virtuel proposant plus de 40 outils dans son application web ; l'API documente chaque outil qu'elle accepte (65 en octobre 2026) derrière un point de terminaison unique de tâche. Ses outils d'image fonctionnent sur les modèles d'images Gemini de Google, et l'API y ajoute le pipeline de staging, la gestion des tâches, les remboursements automatiques pour les rendus échoués et des webhooks signés.

Avant de commencer : clés, environnements et exigences relatives aux images

Obtenir une clé. L'API de Roomagen est en libre-service depuis son lancement public le 30 août 2026 ; il n'y a pas de liste d'attente. Connectez-vous au portail des développeurs avec un compte Roomagen, vérifiez votre e-mail et créez une clé, comme le décrit le démarrage rapide de l'API. Votre première clé ajoute 50 images gratuites, une seule fois par compte, ce qui est suffisant pour concevoir et tester tout ce qui figure dans ce guide. Tant que le compte n'a pas acheté de pack, chaque rendu porte un filigrane Roomagen ; utilisez-les donc pour le développement et les tests, pas pour la publication.

Les clés sont composées de rmg_live_ suivi de 64 caractères hexadécimaux, envoyées dans un en-tête X-Api-Key, et le portail n'affiche chaque clé qu'une seule fois. Conservez-la dans un gestionnaire de secrets côté serveur ; ne l'intégrez jamais dans du JavaScript côté navigateur ou dans une application mobile, où n'importe qui pourrait l'extraire et consommer votre solde.

Environnements. Un compte peut contenir jusqu'à 10 clés actives ; créez-en donc une par environnement et révoquez l'une sans toucher à l'autre. Il n'existe pas de mode test : chaque clé est active, et les clés d'un même compte partagent un solde d'images unique, un webhook de portail et un secret de signature. Attribuez donc aux tâches de développement leur propre webhook_url par tâche. Il n'y a volontairement pas de bouton de rotation : créez la nouvelle clé, déployez-la, puis révoquez l'ancienne.

Images en entrée.

Privilégiez image_url : les requêtes restent légères, vous évitez le surcoût de 33 % du base64, et comme la récupération a lieu pendant votre POST, une URL signée n'a besoin d'être valide que pour cette requête. Envoyez l'export en pleine résolution, une pièce par prise de vue, au niveau du regard et convenablement éclairée ; le modèle ne peut conserver que les détails qu'il peut voir.

Vérifier le solde par le code. GET /v1/account renvoie image_credits, c'est-à-dire le nombre d'images que votre solde peut encore générer. Associez-y dès maintenant une alerte de solde bas : lorsque le solde ne peut pas couvrir une tâche, POST /v1/jobs répond 402 insufficient_credits et aucune tâche n'est créée.

Étape 1 : Soumettre une tâche de staging

Un seul appel POST crée la tâche : l'outil, l'image, les options et, facultativement, une webhook_url spécifique à la tâche (sans elle, Roomagen utilise le webhook du compte enregistré dans le portail, ou bien vous utilisez le 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"
  }'

La réponse arrive avec le statut 201, avant la fin du rendu :

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

Le même appel depuis un backend 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`, // dérivé de votre enregistrement, jamais aléatoire
    },
    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;
}

Le staging est plus strict que les autres outils. Le paramètre style est obligatoire, les options s'écrivent en camelCase, et toute clé absente de la liste ci-dessous, y compris room_type, resolution, tier et customPrompt, est rejetée avec l'erreur invalid_request. Le staging s'exécute toujours en 2K et coûte une image.

Ces trois modes correspondent aux modes de staging de l'application web Roomagen ; votre équipe produit peut donc les tester avant que vous n'écriviez du code : Home Staging Virtuel pour les pièces vides, Redécorer des Pièces Meublées pour restyle et Reconversion de pièce pour recreate.

Persistez les données avant tout. Enregistrez job_id et images_charged en regard de votre propre enregistrement. L'en-tête Idempotency-Key (jusqu'à 128 caractères, propre à votre clé d'API) sécurise les nouvelles tentatives : la même clé avec le même corps de requête renvoie la tâche d'origine, sans facturation supplémentaire. Dérivez les clés à partir de vos enregistrements afin de pouvoir les recalculer après un incident, et renvoyez exactement le même corps : la même clé avec un corps différent, y compris une URL image_url resignée, renvoie 409 idempotency_conflict.

Étape 2 : Gérer l'achèvement — Webhooks contre Polling

Il existe deux manières d'apprendre qu'une tâche est terminée, et les intégrations en production utilisent les deux.

Utilisez les webhooks en priorité et le polling comme filet de sécurité. La documentation de Roomagen qualifie les webhooks d'« optimisation, pas de système de référence », car une livraison est abandonnée une fois la fenêtre de réessais expirée. Le polling seul ne tient pas non plus la charge : à un intervalle de 3 secondes, chaque tâche consomme 20 requêtes par minute ; la limite de 300 par minute sur GET /v1/jobs/{id} couvre donc environ 15 tâches interrogées simultanément.

Configurer le point de terminaison. Enregistrez un point de terminaison https dans l'encart Webhook du portail, en utilisant l'URL finale car les redirections ne sont pas suivies. Conservez le secret de signature whsec_ comme un mot de passe, et déclenchez un événement job.test avec Send test event (Envoyer un événement de test) pendant que vous mettez au point la vérification. Une webhook_url propre à une tâche utilise le même secret.

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

// Corps brut sur cette route, déclaré avant tout express.json() global
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) // les octets bruts, jamais du JSON re-sérialisé
    .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 : seule la première livraison (ou interrogation) fait sortir la ligne du statut "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 }); // téléchargement hors du flux de la requête
  }
  res.sendStatus(200);
});

Quatre détails sont essentiels :

1. Vérifiez sur les octets bruts. L'en-tête correspond à v1= suivi d'un HMAC-SHA256 hexadécimal de {X-Roomagen-Timestamp}.{raw body} ; un JSON re-sérialisé ne correspondra pas.
2. Comparez en temps constant, puis vérifiez la fraîcheur. La fonction timingSafeEqual de Node lève une exception en cas de longueurs différentes ; comparez donc les longueurs au préalable. Rejeter les horodatages datant de plus d'environ cinq minutes empêche les attaques par rejeu, la même mesure de protection que décrit la documentation des webhooks de Stripe ; maintenez les horloges de vos serveurs synchronisées.
3. Répondez rapidement. Roomagen attend un code 2xx pendant 10 secondes ; toute autre réponse, y compris un dépassement de délai, constitue une tentative échouée et fera l'objet d'un nouvel essai.
4. Soyez idempotent. La livraison s'effectue au moins une fois et sans ordre garanti, et votre mécanisme de polling a peut-être déjà finalisé la tâche ; dédupliquez donc sur le job_id.

Pour le polling, durant la phase de développement ou comme mécanisme de réconciliation, la version Python est concise :

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" ou "failed" ; les deux statuts sont finaux
        time.sleep(interval)
    return None  # toujours en traitement : confié au mécanisme de réconciliation

Une tâche se termine avec le statut completed, accompagné de result_urls, ou failed, avec un motif dans error et un remboursement automatique ; consignez processing_ms dans vos logs pour surveiller la latence. Exécutez un script de réconciliation toutes les minutes ou deux pour les tâches affichant toujours processing après plusieurs minutes. Ne marquez pas une tâche lente comme échouée simplement parce qu'un minuteur s'est écoulé : elle peut encore aboutir, et elle a été facturée lors de sa création.

Étape 3 : Délivrer les résultats à vos utilisateurs

Une tâche achevée renvoie result_urls, un tableau d'images JPEG générées. Ne pratiquez pas le hotlinking sur ces URL.

Réhébergez les résultats. Roomagen distribue les résultats depuis son propre stockage, sous réserve des règles de rétention du compte. Une tâche d'arrière-plan doit donc télécharger chaque image dès la fin de la tâche, l'écrire dans votre propre bucket (S3, R2, GCS ou similaire) et la distribuer via votre CDN. Vos images ne dépendent ainsi jamais de la politique de rétention d'un fournisseur.

Conservez l'original à côté du résultat généré. Stockez la photo source et l'image mise en scène sous forme de paire associée. Cette paire alimente un curseur avant / après, permet aux utilisateurs de revenir en arrière, et correspond à ce qu'exigent les règles de divulgation des annonces immobilières (Étape 4).

Anticipez les variations. La production générative varie, et il arrive que le canapé ne convienne pas. Une nouvelle exécution constitue une nouvelle tâche qui coûte une autre image, car Roomagen rembourse les rendus qui échouent techniquement, pas les résultats qui déplaisent à un utilisateur. Attribuez à chaque nouvelle exécution son propre en-tête Idempotency-Key, comme photo-4821-stage-2 : réutiliser la première clé renvoie la tâche initiale, ou une erreur 409 si le corps a changé. Proposez un bouton « Réessayer », et décidez si ce coût est visible pour les utilisateurs ou inclus dans votre tarification.

Concevez les états d'attente et d'échec. Le staging prend généralement moins d'une minute, ce qui est long à l'échelle d'une interface utilisateur. Concevez l'état de progression, l'état d'échec (« le rendu a échoué et a été remboursé ») et l'action de réessai avant la mise en production.

Étape 4 : Intégrer la divulgation dans votre modèle de données

Si vos utilisateurs publient des photos retouchées dans des annonces immobilières, la divulgation est une obligation légale pour eux, et votre modèle de données détermine si cette tâche est simple ou non. L'API de Roomagen n'ajoute aucune étiquette de divulgation ni d'association original-retouche, et les conditions d'utilisation de Roomagen placent la responsabilité de la divulgation sur l'utilisateur ; votre intégration doit donc s'en charger.

• Loi californienne AB 723, en vigueur depuis le 1er janvier 2026. Un courtier ou un négociateur immobilier, ou toute personne agissant pour son compte, qui utilise une image modifiée numériquement dans une annonce de vente immobilière doit indiquer, sur l'image ou juste à côté, qu'elle a été modifiée, et ajouter un lien, une URL ou un code QR renvoyant vers un site public montrant l'image originale non retouchée. Le régulateur immobilier de Californie ajoute que lorsqu'un outil d'IA produit une publicité trompeuse, la responsabilité incombe « au titulaire de la licence et à son courtier responsable, et non au fournisseur de technologies ».
• Annonces de location en Californie à partir du 1er janvier 2027. La loi AB 2025 étend des exigences similaires de divulgation aux annonces de location, ciblant les bailleurs et d'autres acteurs, et pas uniquement les titulaires de licence.
• Les règles des MLS divergent sur l'emplacement. Canopy MLS exige l'étiquette sur l'image elle-même, et pas seulement dans les légendes, tandis que NWMLS refuse les photos comportant des graphismes ou du texte superposés.
• Produits destinés au marché européen. Depuis le 2 août 2026, l'article 50 du règlement européen sur l'IA (EU AI Act) impose aux déployeurs de systèmes d'IA qui génèrent ou manipulent des images de type « deepfake » (contenu ressemblant à des lieux ou objets existants qui paraîtrait faussement authentique) de le divulguer, une définition que les photos d'un bien immobilier lui-même retouchées par l'IA peuvent tout à fait remplir (voir notre guide sur l'article 50 de l'EU AI Act).

Stockez donc la divulgation sous forme de données et non de pixels : une URL publique pour la photo d'origine, un indicateur booléen altered accompagné de l'outil et des options utilisés, ainsi qu'un texte de divulgation et un positionnement d'étiquette pour chaque destination. Générez l'étiquette au moment de l'exportation, pas lors du stockage.

Il s'agit d'un récapitulatif pour les développeurs et non d'un conseil juridique ; notre guide de conformité AB 723 et règles MLS pour les photos par IA et notre guide des exigences photo MLS et de divulgation du home staging virtuel traitent ce sujet plus en détail.

Enjeux de production : limites de débit, réessais et budget de crédits

Limites de débit. Par clé, dans une fenêtre glissante de 60 secondes : 60 requêtes par minute pour POST /v1/jobs, 300 pour GET /v1/jobs/{id} et 120 pour GET /v1/tools et GET /v1/account, plus 600 requêtes par minute par IP cliente, partagées entre tous les serveurs situés derrière une même adresse NAT. Les réponses positives comportent les en-têtes X-RateLimit-Limit et X-RateLimit-Remaining ; une erreur 429 rate_limited renvoie un en-tête Retry-After en secondes : respectez-le au lieu d'inventer votre propre algorithme de backoff. Pour les traitements volumineux, placez les soumissions dans une file d'attente : à 60 tâches par minute, 500 photos prennent un peu plus de huit minutes à être soumises.

Réessais et codes d'erreur. Chaque erreur se présente sous la forme { "error": { "code", "message", "doc_url" } }. Conditionnez votre logique sur code, jamais sur message :

Impact financier des échecs. Une tâche qui échoue pendant la génération est remboursée automatiquement, mais le champ images_charged associé à la tâche n'est pas réécrit ; considérez donc l'appel GET /v1/account comme la source de référence pour votre solde. Lorsque vous comparez des prestataires, examinez leurs politiques de gestion des échecs autant que leur prix.

Budgétisation des crédits. Roomagen facture l'API en images, achetées à l'avance sous forme de packs depuis le portail des développeurs :

Les packs n'expirent jamais et se cumulent. Chaque outil documenté coûte une image par rendu en 2K, l'option resolution: "4K" double ce coût sur les outils qui la prennent en charge, et le staging coûte toujours une seule image. Pour établir votre budget, prévoyez les relances : une plateforme réalisant le staging de 1 200 photos par mois et prévoyant une relance sur dix a besoin d'environ 1 320 images ; un pack Growth couvre ainsi presque deux mois.

Les tarifs publics varient considérablement (relevés en octobre 2026) : ModelsLab annonce 0,02 $ par rendu d'intérieur, Decor8 0,20 $ par image pour toutes les opérations d'API, et AI HomeDesign 0,24 $ par photo avec facturation annuelle ou environ 0,49 $ avec facturation mensuelle. Comparez l'étendue des outils, les webhooks, la politique de remboursement des échecs et la qualité du rendu autant que le prix unitaire ; notre guide des tarifs des API de home staging virtuel et notre comparatif des API de staging détaillent chaque fournisseur.

Une mise en garde honnête sur la maturité. L'API de Roomagen est récente : la version 1 a été lancée le 30 août 2026 avec un point de terminaison unique pour les tâches, et sa documentation ne couvre l'intégralité des outils acceptés que depuis le 3 octobre 2026. Elle dispose donc des conventions actuelles, mais pas d'années d'historique public. Les modifications de rupture sont annoncées par e-mail aux comptes possédant une clé active avant leur déploiement ; des ajouts peuvent être introduits à tout moment, ignorez donc les champs de réponse que vous ne reconnaissez pas.

Étendre l'intégration : autres outils documentés

Une fois la boucle opérationnelle pour le staging, proposer un bouton « version crépuscule » ou « désencombrer » ne demande de modifier que tool et options :

Ces outils acceptent également resolution (2K ou 4K), tier (auto, guided ou custom) et customPrompt (jusqu'à 500 caractères). Contrairement au staging, ils ignorent les clés inconnues en les listant dans le tableau warnings de la réponse, mais rejettent tout de même les valeurs hors limites. Pour les pièces sans fenêtre, envoyez hasWindows: false à l'outil de retouche jour en crépuscule pour que le prompt n'intègre pas d'instructions de fenêtres et de vue extérieure.

GET /v1/tools renvoie l'ensemble des slugs que votre clé peut appeler, avec leur coût en images, et chaque slug renvoyé est documenté. Lisez cette liste dynamiquement au lieu de l'inscrire en dur dans le code, et n'oubliez pas que les noms d'outils affichés sur roomagen.com ne sont pas les slugs de l'API.

Ce que l'API ne fait pas

• Pas de point de terminaison de lot. Une tâche correspond à une seule image traitée par un seul outil ; le traitement par lot de l'application web ne fait pas partie de l'API, vous devez donc gérer la file d'attente des tâches en respectant les limites de débit.
• Pas d'étiquettes de divulgation. Les sorties ne comportent aucune étiquette de divulgation ni de paire avant/après. Les rendus portent un filigrane tant que le compte n'a pas acheté de pack, et sont totalement exempts de marque Roomagen par la suite.
• Pas de regénération gratuite. Une nouvelle exécution est une nouvelle tâche et fait l'objet d'une facturation standard.
• Pas de mesures ni de fichiers CAO. Les sorties sont des images JPEG, et non des cotes, des vecteurs ou des fichiers DWG. Si vous devez extraire les dimensions d'une pièce à partir de photos, une API d'images génératives n'est pas l'outil adapté.
• Aucune garantie sur le résultat. Les modèles génératifs peuvent générer des artéfacts ou des imprécisions ; vérifiez le résultat avant qu'il ne rejoigne une annonce.
• Pas d'accès aux fonctionnalités exclusives à l'application web. Le bouton Retoucher, la Bibliothèque et le chat Compagnon de design sont réservés à l'application web de Roomagen.

Erreurs courantes dans les intégrations d'API de staging

1. Bloquer le thread de requête. Laisser la requête d'un utilisateur ouverte pendant le rendu d'une tâche provoque des dépassements de délai au niveau de l'équilibreur de charge. Renvoyez 202 Accepted depuis votre propre API et poussez les mises à jour au client.
2. Mauvais noms d'options. Envoyer room_type ou resolution sur une tâche de staging renvoie invalid_request ; le staging exige des clés en camelCase issues de sa propre liste, ainsi que le paramètre style.
3. Se fier uniquement aux webhooks. Après environ 36 minutes de réessais, Roomagen cesse ses tentatives. Sans script de réconciliation, la tâche reste indéfiniment bloquée en statut « processing ».
4. Vérifier la signature de manière incorrecte. Hacher du JSON analysé, omettre le préfixe d'horodatage, comparer avec === ou faire l'impasse sur la vérification de fraîcheur affaiblit la sécurité de la vérification.
5. Une URL de webhook avec redirection. Les URL en simple http et les hôtes privés sont refusés immédiatement avec l'erreur webhook_url_rejected, et les redirections ne sont pas suivies : un slash final manquant ou une redirection vers les www fait échouer chaque livraison.
6. Clés d'idempotence aléatoires ou URL resignées. Une clé que vous n'avez pas stockée ne peut pas être rejouée, et la relance donne lieu à une nouvelle facturation ; une URL image_url resignée avec la même clé renvoie une erreur 409.
7. Pratiquer le hotlinking sur les URL de résultat. Les résultats sont soumis aux règles de rétention du fournisseur. Réhébergez-les dès que la tâche est terminée.
8. Un filigrane unique pour toutes les destinations. Une étiquette « Virtually Staged » (Mise en scène virtuellement) incrustée directement dans les pixels peut enfreindre les règles des MLS interdisant le texte superposé, et sans lien vers l'original, elle ne satisfait pas à elle seule les exigences de l'AB 723.

Liste de contrôle avant le déploiement

• La clé d'API réside exclusivement sur vos serveurs, à raison d'une par environnement.
• Les requêtes de staging transmettent toujours style et aucun paramètre hors de la liste d'options de staging.
• Chaque tâche possède un en-tête Idempotency-Key dérivé de vos enregistrements, et les réessais renvoient le corps d'origine à l'identique.
• Le point de terminaison de webhook est l'URL https finale, vérifie les signatures v1= sur le corps brut, rejette les horodatages obsolètes et répond en moins de 10 secondes.
• Une notification job.test envoyée depuis le portail passe la vérification avec succès.
• Un script de réconciliation vérifie les tâches toujours en traitement après plusieurs minutes.
• Les résultats sont réhébergés, chacun avec sa photo d'origine conservée à ses côtés.
• Les données de divulgation (URL de l'original, marqueur de retouche, étiquette par destination) accompagnent chaque flux d'exportation.
• Une alerte de solde bas surveille image_credits, et chaque code d'erreur est traduit en un message clair pour vos utilisateurs.

En conclusion : déployez la boucle, puis étendez-la

Ajouter le home staging virtuel à une application représente une intégration modeste : un appel POST avec une clé d'idempotence, un gestionnaire de webhook vérifié secondé par un mécanisme de réconciliation, et une étape de stockage qui conserve l'original à côté du résultat. Le scénario nominal ne demande que quelques dizaines de lignes de code ; le gros du travail consiste à fiabiliser l'ensemble pour la production et à gérer les données de divulgation. Rien de tout cela n'est lié à un fournisseur unique : la soumission asynchrone, la confirmation mêlant push et pull, les résultats réhébergés et l'association image source / image finale conviennent à n'importe quelle API de staging.

Pour développer votre intégration sur la base de cet exemple concret, obtenez une clé d'API Roomagen : la première clé inclut 50 images gratuites, et le guide de démarrage rapide, le guide des webhooks ainsi que la référence des erreurs en détaillent les spécificités. La même boucle de tâches permet ensuite d'exécuter le Home Staging Virtuel, la Retouche & Conversion Photo Jour en Crépuscule, la Suppression d'objets et d'éléments par IA dans les photos, l'Amélioration de photos, la Rénovation et Remodelage Virtuels et le Plan d'étage en 3D au sein d'une seule et même intégration.