En ligne  
Partner Programs App Development · Montée en iframe

Intégrez dans
notre shell.

Une app AT est une app web que vous savez déjà coder — rendue dans le shell AppointmentTrader à une URL propre, /apps/{id} avec une entrée dans la barre latérale, synchronisation de thème, et un token SDK scoped pour l’utilisateur actif. Lisez les données AT, placez des enchères, publiez dans le flux communautaire, installez dans le portail utilisateur à côté de nos surfaces.

  • iframemontée sur /apps/{id}
  • 0réécritures pour modules legacy
  • SDKscopé à l’utilisateur actif
Comment fonctionne réellement une app AT

Trois étapes. Un manifeste.

  1. 01

    Ajoutez une entrée au manifeste

    Déposez votre id d’app, URL d’entrée, et liste blanche de menu dans /config/atv2-apps.php. The host page at /apps/{id}/{subpath} rend le shell v2, affiche votre menu dans la barre latérale, et intègre votre entryUrl dans un iframe sandboxé.

  2. 02

    Utilisez les données AT via le SDK

    Les apps first-party (même origine) appellent /v1/... directement avec la session utilisateur. Les apps tierces (cross-origin) demandent des capacités via un broker postMessage — le même pont qui contrôle la publication, la lecture de profils, la consultation de transactions. Synchronisation de thème, navigation, et auth passent automatiquement.

  3. 03

    Installez dans le portail utilisateur

    Une fois enregistrée, votre app apparaît comme une ligne dans la barre latérale AT — aux côtés d’Accueil, Tendances, Vendeurs. Les utilisateurs y naviguent comme vers toute autre surface. Les changements de sous-chemin passent par postMessage ; le parent contrôle la barre d’adresse pour une navigation interne native, sans iframe visible.

Ce qu’une app peut faire

Six primitives. Toutes les données AT sont accessibles.

La même surface API qui alimente AppointmentTrader, exposée à votre app avec le scope demandé et accordé par l’utilisateur.

Lire les données AT
/v1/marketdata/get_world_top · /v1/location/search · /v1/user/get_profile
public + clé API
Placer & suivre des enchères
/v1/concierge/categorize_request · /v1/transaction/list
clé API + autorisation utilisateur
Publier dans le fil d’actualité
/v1/community/set_create_post · /v1/community/set_thumbs_up
clé API + vérification
S’abonner aux événements
/v1/notification/subscribe · bid.filled, transaction.confirmed (HMAC webhooks)
clé API + webhook
Rendre dans le shell
iframe at /apps/{appId}/{subpath} · theme sync · nav allowlist
manifeste uniquement
Installer dans un portail
sidebar entry · per-user enable rows (DB-backed registry, in progress)
manifeste + revue
Publier dans la communauté

Votre app poste directement dans le fil.

Le fil communautaire AT est un endpoint comme un autre. Une app peut composer un post, joindre des médias, mentionner des utilisateurs, et l’envoyer — mêmes limites de débit, mêmes contrôles de vérification, même éditeur que la plateforme utilise en interne. Un bot d’enchères annonce un remplissage. Un outil de fidélité célèbre la 100e transaction d’un invité. Un widget Encore poste la couverture récupérée de la soirée.

POST /v1/community/set_create_post

Throttle de composition de 15 secondes par session · contrôle de vérification de compte · identique à l’éditeur in-app.

La publication depuis une app utilise l’identité de l’utilisateur, pas celle de l’app. Vous demandez, ils accordent, vous publiez en leur nom. Révocable à tout moment depuis la barre latérale.

Apps déjà en fonctionnement

Trois à nous. Deux à eux. Une place libre.

Vue d’ensemble de l’hôte d’app

Transactions

Interne

Le grand livre complet d’un utilisateur — dépôts, paiements, remboursements, reçus de frais. Rendu dans le shell AT, entrée dans la barre latérale, module legacy encapsulé en app dès le premier jour.

Menu Activité · Relevés · Reçus

Discussion

Interne

Messagerie acheteur/vendeur liée aux transactions en cours. Même modèle iframe : module legacy rendu dans /apps/chat/ sans réécriture, récupère le changement de thème et la navigation inline gratuitement.

Menu Boîte de réception · Conversations

Alertes

Interne

Centre d’alerte système d’un utilisateur — enchère remplie, transaction confirmée, message reçu. S’abonne aux mêmes sujets /v1/notification que toute app tierce.

Menu Tous · Mentions · Paramètres

Concierge (partner sample)

Tierce partie · Hôtel

Tableau de bord concierge interne d’un hôtel — formulaire d’entrée, calculateur de récompenses, flux de prise en charge des membres — rendu pour l’équipe front-office. Communique avec les endpoints d’enchères AT via le SDK ; pousse les reçus de remplissage invités dans le PMS de la propriété.

Menu Demandes ouvertes · Remplies · Équipe

Encore Floor (partner sample)

Tierce partie · Restaurant

Surface du manager restaurant « places libérées ce soir ». Liste ce qu’Encore remplit en temps réel, les convives payants, quelle entrée de réservation mettre à jour. Scoped au token SDK pour une seule propriété.

Menu Ce soir · Cette semaine · Rapports

Le vôtre ensuite ?

Place libre

Une surface qui n’existe pas encore — une app shopping-clienteling pour une maison de luxe, un tableau de bord de futures tee-times pour un club, une transcription côté lieu de chaque enchère placée contre une propriété.

Menu Parlez-nous
0
réécritures de code pour encapsuler un module legacy en app
5s
budget handshake SDK avant erreur hôte
2
niveaux de confiance — first-party (session) et tierce partie (broker)
$0
frais de distribution — partage de revenus uniquement sur transactions que vous générez
Partenaires développant des outils personnalisés

Un second bureau pour les ventes — votre design.

Le meilleur usage d’App Development aujourd’hui est l’outillage interne partenaire : un tableau de bord concierge hôtelier qui communique avec les enchères AT, une vue de plancher Encore restaurant qui affiche la couverture récupérée ce soir, une surface de vente qui liste les invités AT actifs d’une maison de luxe. Le broker de capacités est réservé à cela — apps partenaires demandant des actions fournies par AT dans un sandbox contrôlé par la plateforme.

Si vous êtes déjà dans les Elevé ou Encore programmes, une app interne est la prochaine étape naturelle. Votre équipe construit la surface ; nous exposons les données, l’auth, et le rail d’installation.

FAQ

Les réponses honnêtes.

En quoi App Development diffère-t-il de l’intégration API ?

L’intégration API est votre stack appelant AT depuis l’extérieur — vous possédez l’UI, les utilisateurs, la distribution ; vous voulez juste les données AT. App Development est l’inverse : vous livrez une UI dans AT — une entrée dans la barre latérale, une URL propre dans notre shell, installation dans le portail utilisateur. Mêmes endpoints sous le capot ; portée différente. Le bon choix quand vos utilisateurs vivent déjà sur AT ou que vous voulez qu’ils y soient.

Que peut réellement lire ou faire mon app avec les données AT ?

Tout ce que fait l’app web AT, limité par ce que l’utilisateur a accordé. Lire données marché, recherche de lieu, profils publics. Avec une clé API scoped plus une autorisation par utilisateur : placer des enchères, suivre transactions, s’abonner aux webhooks, poster dans le fil communautaire au nom de l’utilisateur. Les capacités sont déclarées dans le manifeste app et accordées à l’installation — les utilisateurs voient les mêmes scopes que vous livrez, et peuvent révoquer depuis un écran unique.

Mon app peut-elle vraiment poster dans le fil AT ?

Oui. POST /v1/community/set_create_post avec {boardId, title, body} — the same endpoint the in-app composer uses. The post arrives with the user’s name on it (your app posts on their behalf, not as itself), and the same per-session 15-second throttle and account-verification gates apply. Apps that need to ship public-feed updates are exactly what this surface was built for.

Comment les utilisateurs installent-ils réellement une app ?

Aujourd’hui, les apps enregistrées vivent dans /config/atv2-apps.php et apparaissent comme des lignes dans la barre latérale pour tous. Le registre DB avec activation par utilisateur est en cours — les utilisateurs installeront depuis une surface de découverte, les scopes seront revus à l’accord, et l’entrée barre latérale apparaîtra dans leur portail à côté d’Accueil, Tendances, Vendeurs, et Partenaires. Pour les outils internes partenaires, l’installation est par propriété et invisible aux autres locataires.

Dois-je réécrire mon app web existante ?

Non. L’hôte enlève le shell v2 en servant votre URL dans l’iframe et enveloppe le corps dans une enveloppe minimale. Même index.php gère le mode plein écran et le mode embed — vous n’avez même pas besoin de détecter ?embed=1. We literally wrapped three legacy modules (Transactions, Chat, Notifications) as v2 apps on day one with no code changes. The bridge script is auto-injected; you only ship one if you’re cross-origin.

Comment fonctionne la barre d’adresse de l’iframe ?

L’hôte la contrôle. Les URLs lisent toujours /apps/{appId}/{subpath} — never the iframe’s real origin. Your app emits a {type:'navigated', path} postMessage quand elle change de route ; le parent appelle history.pushState pour garder l’adresse exacte. Rechargements, bouton retour, liens profonds — tout natif, tout propre. L’utilisateur ne voit jamais la couture de l’iframe.

Quel est le coût de la distribution via AT ?

Distribution gratuite. Nous partageons les revenus uniquement sur les transactions qu’une app génère — si l’app conduit une enchère remplie par AT, nous partageons les frais ; si l’app est un outil qui ne déplace pas d’argent, aucun coût. Le niveau gratuit API (10k appels/mois sur endpoints liés à l’utilisateur) couvre la plupart des outils internes partenaires de bout en bout. Pas de SaaS, pas de licence par siège.

Apportez un outil. Nous apportons le rail.

Un appel de 20 minutes avec le responsable partenariats. Nous parcourrons le manifeste, le SDK, le chemin d’installation, et ce que vos utilisateurs verraient dans leur barre latérale.

Déjà dans Elevé ou Encore ? Une app interne est la prochaine étape naturelle. Back to Partner Programs.