← Tous les manuels ·
PortailMANUAL — aios-automations
Manuel de l'app. À LIRE avant toute intervention, à METTRE À JOUR après chaque modif (CHANGELOG en bas).
Créé le 2026-08-21.
1. Identité
- Rôle : héberge les webhooks/automatisations rapatriés depuis Make vers l'AIOS. Une route = un scénario Make migré.- Entité : transverse (RP / MOA / MP selon la route).
2. Exécution / infra
- Dossier : /root/workspace/apps/aios-automations- Stack : Python, FastAPI, uvicorn- Service systemd : aios-automations.service (systemctl restart aios-automations.service)- Port : 8363 (127.0.0.1)- URL publique : https://automations.panelbay.com (Cloudflare + nginx + Let's Encrypt)
3. Fichiers clés
- server.py — l'app + les routes.
4. Auth
- Token partagé AUTOMATIONS_TOKEN dans /root/aios/.env.- Passe en query ?token=... (pratique pour un script Airtable) ou header Authorization: Bearer ....
5. Routes
- GET /health — statut.- POST /rp/agent-assigned — DÉSACTIVÉE le 2026-08-31 (retourne 410). Ancienne migration Make #1 (Client RP agent immo assigné).- - Historique : source = automatisation Airtable base RP
appGzbfkhHiO95jd1, table Clientes tblGscoeyEVybGVHN, automatisation "Agent immo assigné > alerte mail" (wflzO8JcPmLO91FGV), déclenchée quand Agente inmobiliario asignado (fldXMHEx5ZZdwrbhX) n'est pas vide. Payload { recordId, email (agent assigné), nombre, phone }. Envoyait un mail HTML "Nuevo lead asignado" (ES) à l'agent, expéditeur resident.paraguay@gmail.com. - - Abandon du process d'assignation manuelle d'agent RP sur Airtable. Reste à faire côté Airtable (manuel, Matt) : désactiver/supprimer l'automatisation
wflzO8JcPmLO91FGV et supprimer le champ Agente inmobiliario asignado (fldXMHEx5ZZdwrbhX) sur la table Clientes.
- POST /rp/onboarding-submit — Migration Make #4 (onboarding RP -> Airtable + contrat eSignatures). Voir rp_onboarding.py et make-migration/SPEC-04-onboarding-contrat.md.- - Payload :
{ invitation:{token,language,pack,permanente_upsell}, family:{...}, persons:[{identity,administrative,package}], metadata:{submitted_at,currency,deposit_amount}, pricing:{group_total,group_currency,group_balance_due,adults_count,per_adult_share} }. - - Effet : cree la fiche dossier (Airtable base RP
appGzbfkhHiO95jd1, table tbld8zAoTQS1BIqmi) + une fiche par personne (tblGscoeyEVybGVHN, liee au dossier), puis 1 contrat eSignatures par ADULTE (age >= 18) dans la langue du client (template selon pack x langue). Enfants = fiche seule, pas de contrat. - -
?test=yes -> contrats eSignatures en mode test (non factures, non envoyes). Teste bout en bout le 2026-08-22. - - Routage pack : temporaire/fiscal + upsell Permanente -> template "permanent". Investor Pass = template a creer.
6. Secrets
- AUTOMATIONS_TOKEN dans /root/aios/.env (JAMAIS la valeur ici).- Envoi Gmail : token OAuth du compte resident.paraguay@gmail.com dans data/.creds/google_accounts/.- RP_CRM_INGEST_KEY dans /root/aios/.env : clé x-api-key du CRM RP (rp-crm) pour créer des prospects via POST http://127.0.0.1:8332/api/ingest. Optionnel RP_CRM_INGEST_URL (défaut = URL locale ci-dessus).- MOA_CRM_INGEST_KEY dans /root/aios/.env (= la MOA_INGEST_API_KEY de moa-crm/backend/.env) : lead "a assigner" dans le CRM MOA via POST http://127.0.0.1:8310/api/leads/ingest.- ESIGNATURES_API_KEY dans /root/aios/.env : API eSignatures.io (contrats onboarding RP #4). Templates surchargeables via ESIG_TEMPLATES_JSON. Ecriture Airtable via AIRTABLE_WRITE_TOKEN.
7. Pièges connus
- Pas de route / (le healthcheck de l'expose skill sur / renvoie un warning bénin ; utiliser /health).- Le compte expéditeur doit avoir le scope gmail.send (OK pour resident.paraguay).
8. CHANGELOG
- 2026-08-21 — Création de l'app + route /rp/agent-assigned (migration Make #1). Service systemd + expose automations.panelbay.com. Testé (envoi réel OK, auth 401 sans token). Reste : repointer le script Airtable vers cette URL puis désactiver le scénario Make.
CHANGELOG
- 2026-08-22 : routes migration Make #5 (POST /rp/lead-magnet-5errores, guia "5 errores" au prospect, expediteur resident.paraguay) et #6 (POST /moa/lead-magnet-notif, notif "Nouveau Prospect Immo" a moarealestate.sa) ajoutees. Payload systeme.io {data:{contact:{email,fields:{first_name,phone_number}}}}. Testees 200 OK. Reste cote Matt : repointer les webhooks systeme.io + supprimer scenarios Make #5/#6.- 2026-08-22 : #5 cree desormais aussi un prospect dans le CRM RP (rp-crm) de Younes en plus d'envoyer la guia. Helper _rp_crm_ingest() (best-effort, n'echoue jamais la reponse) -> POST /api/ingest, source "lead_magnet", statut "nouveau", note "guia 5 errores". Nouvelle cle RP_CRM_INGEST_KEY dans .env. Reponse enrichie du flag "crm". Teste bout en bout : mail 200 OK + prospect cree (source lead_magnet, statut nouveau), lead de test ensuite supprime du CRM.- 2026-08-22 : #6 alimente en fait par 5 regles systeme.io distinctes pointant toutes le meme webhook Make (Civis Aether, Jardinia, Civis X & XI, Veralta, VSL IMMO). La route /moa/lead-magnet-notif lit desormais un param query ?brochure=... (fallback corps page/funnel, sinon libelle generique) et l'affiche dans le sujet + le corps de la notif. Matt doit repointer LES 5 regles vers l'URL AIOS, chacune avec son ?brochure= propre. Teste OK avec et sans brochure. Repointe + teste bout en bout (Jardinia) le 2026-08-22.- 2026-08-22 : #6 cree aussi un lead "a assigner" dans le CRM MOA Real Estate (moa-crm, POST http://127.0.0.1:8310/api/leads/ingest) en plus de la notif. Helper _moa_crm_ingest() (best-effort), source "lead_magnet", tag = brochure, stage "sans_contact" + assignee NULL (dedoublonne serveur). Cle = MOA_CRM_INGEST_KEY dans /root/aios/.env (= la MOA_INGEST_API_KEY existante de moa-crm/backend/.env ; NE PAS la regenerer). Reponse enrichie du flag "crm". Teste bout en bout (Veralta) : notif + lead cree "a assigner", lead de test supprime ensuite. NB : le vrai .env de moa-crm est backend/.env (dotenv lit le cwd), PAS le .env racine.- 2026-08-22 (suite) : onboarding RP trilingue cote suivi Airtable. create_dossier_record() ecrit desormais la langue "es" en plus de fr/en dans le champ singleSelect "Idioma" (fld7mLayCg2gxva0E, base appGzbfkhHiO95jd1 / table Dossier tbld8zAoTQS1BIqmi). L'option "es" (selOhs0zRWOQlpixx) a ete creee dans Airtable via un enregistrement jetable avec typecast:true (le PAT AIRTABLE_WRITE_TOKEN n'a PAS le scope schema.bases:write, mais typecast cree l'option a la volee). Le champ "Idioma" cote Clientes (fldSm0IOS8n5pW2pv) est un singleLineText, il acceptait deja n'importe quelle langue. La generation du contrat ES etait deja operationnelle (rp-contracts) independamment de ce champ ; ce changement ne concerne que la tracabilite du dossier. Service redemarre.- 2026-08-31 : route /rp/agent-assigned desactivee (retourne 410) a la demande de Matt : le process d'assignation manuelle d'un agent RP sur Airtable est abandonne, l'idee d'automatiser cette assignation (notee precedemment) n'a donc plus lieu d'etre. Service redemarre, verifie (410 + /health OK). Reste manuel cote Matt : desactiver/supprimer l'automatisation Airtable wflzO8JcPmLO91FGV et supprimer le champ Agente inmobiliario asignado sur Clientes (aucun outil API dispo pour ca : pas de tool MCP de suppression de champ, et le PAT n'a pas le scope schema.bases:write). A noter : le portail client de rp-dashboard (/c/:token) affiche l'agent lu depuis ce champ ; sa suppression fera juste disparaitre cet affichage, sans casse.