← Tous les manuels · Portail
↗ Ouvrir l'app

MANUAL — 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é).
  • - POST /rp/onboarding-submit — Migration Make #4 (onboarding RP -> Airtable + contrat eSignatures). Voir rp_onboarding.py et make-migration/SPEC-04-onboarding-contrat.md.
  • 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.