API

Les clés se créent dans l'app : Profil → Clés API → +. En créer une demande le niveau 4 (vérification formelle), la même barre que les comptes business — une clé agit en votre nom hors de l'app, on ne la confie donc qu'à un compte qu'un admin a identifié. Lister et révoquer restent possibles à tous les niveaux.

• —Nom — pour vous y retrouver (« Studio Midbar »).
• —Publier en tant que — votre compte personnel, ou l'un de vos comptes business. Une clé épinglée sur un business ne peut publier QUE sous cette identité ; nommer une autre identité dans une requête est refusé.
• —Autoriser la publication — coupé, la clé ne peut que lire.

Le secret (msk_live_…) n'est affiché qu'une fois. Le serveur n'en garde que le SHA-256 : il est irrécupérable — une clé perdue se révoque et se remplace. Vous pouvez détenir jusqu'à 20 clés actives, chacune avec une expiration facultative allant jusqu'à dix ans.

Envoyez la clé comme jeton bearer. L'en-tête X-API-Key est accepté aussi, pour les clients qui se réservent Authorization.

curl https://api.mishkan.tech/api/users/me \
  -H "Authorization: Bearer $MISHKAN_KEY"

Une clé inconnue, révoquée ou expirée répond le même 401 — volontairement : sonder l'API n'apprend rien à un attaquant.

Une clé porte posts:read, posts:write, notifications:write, ou n'importe quelle combinaison. Tout le reste — messages, Mem, vérification, administration, et la gestion des clés elle-même — reste réservé à une session signée dans l'app. Une clé qui fuite ne peut ni en créer une autre, ni lire vos conversations, ni vider votre solde.

• —posts:read — lire le fil, une publication, vos publications, vos comptes business.
• —posts:write — publier et supprimer.
• —notifications:write — prévenir le propriétaire de la clé, et lui seul. Jamais accordée par défaut : demandez-la à la création de la clé, ou activez-la ensuite depuis sa ligne dans l'app.

Publier dans le fil d'un groupe (conversation_id) remplace le gate de niveau par l'appartenance au groupe et sa politique de publication, et paie le prix du groupe à son propriétaire.

curl "https://api.mishkan.tech/api/feed?kind=text&limit=20" \
  -H "Authorization: Bearer $MISHKAN_KEY"

Une publication sur le fil public coûte 2 מ et demande la vérification mezouza (niveau 3). Le débit est remboursé si l'enregistrement échoue.

POST /api/posts publie du texte et des liens, en JSON :

curl -X POST https://api.mishkan.tech/api/posts \
  -H "Authorization: Bearer $MISHKAN_KEY" \
  -H "Content-Type: application/json" \
  -d '{"content":"Chag sameach","language":"en"}'

POST /api/posts/visual publie un reel ou un carrousel en multipart/form-data : 1 à 10 fichiers, dans l'ordre du formulaire, 30 Mo pour la requête entière. La légende va dans content (1000 caractères), et les mêmes champs facultatifs s'appliquent.

curl -X POST https://api.mishkan.tech/api/posts/visual \
  -H "Authorization: Bearer $MISHKAN_KEY" \
  -F "content=Kabbalat Shabbat, 18:30" \
  -F "media=@reel.mp4;type=video/mp4"

POST /api/posts/youtube publie un reel adossé à une vidéo YouTube. url désigne la vidéo ; link_url est un bouton « En savoir plus » distinct — renseignez les deux si vous voulez les deux.

curl -X POST https://api.mishkan.tech/api/posts/youtube \
  -H "Authorization: Bearer $MISHKAN_KEY" \
  -H "Content-Type: application/json" \
  -d '{"url":"https://youtu.be/abc123","link_url":"https://example.org"}'

Une intégration qui s'arrête la nuit — plus de crédit, jeton expiré, quota atteint — ne le dit à personne : l'erreur part dans les logs d'un ordonnanceur, et on la découvre trois jours plus tard en s'étonnant que rien n'ait été publié. Avec notifications:write, une clé écrit dans le centre de notifications de son propriétaire, et le push part comme pour le reste.

Une clé prévient SON propriétaire, et personne d'autre. Le destinataire n'est pas un champ de la requête — il EST l'identité de la clé, il n'y a donc rien à falsifier pour atteindre quelqu'un d'autre. Ce canal ne peut pas devenir un mégaphone.

curl -X POST https://api.mishkan.tech/api/notifications \
  -H "Authorization: Bearer $MISHKAN_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "title": "Autopilot stopped",
    "body": "Anthropic credit exhausted — nothing published since 03:12.",
    "source": "TorahWithLLM",
    "level": "error",
    "url": "https://console.anthropic.com/settings/billing",
    "dedupe_key": "anthropic-credit"
  }'

202 quand elle part. Une répétition dédupliquée répond 200 avec deduped: true et l'identifiant de la notification déjà envoyée — la requête a réussi et rien n'est parti :

{ "delivered": true, "remaining_today": 59 }
{ "id": "…", "delivered": false, "deduped": true, "remaining_today": 59 }

dedupe_key est ce qui rend une boucle d'alerte supportable : un pilote qui retente toutes les dix minutes sans crédit enverrait sinon la même ligne 144 fois par jour. En dessous, un plancher dur de 60 notifications par compte et par 24 h, au-delà duquel la route répond 429 ; remaining_today revient à chaque appel pour lever le pied avant.

Le titre et le corps sont affichés tels quels, dans toutes les langues : le serveur ne sait pas ce que votre intégration voulait dire, et le deviner en trois langues serait une invention. Une clé épinglée sur un business notifie sous cette identité — l'alerte apparaît dans l'app sous ce compte, pas dans le centre personnel — et dedupe_key y est porté aussi, deux commerces employant la même clé décrivant deux pannes différentes.

{ "error": "missing the posts:write scope" }

Balayez la clé (iOS) ou touchez la corbeille (Android), ou appelez DELETE /api/api-keys/{id} avec un jeton de session. L'effet est immédiat. Les publications déjà faites restent en ligne : révoquer un identifiant n'est pas retirer ce qui a été publié avec.