Pattern : host connector en api_in + event_out

Utilisez ce pattern lorsqu’un ERP, un e-commerce ou un autre système métier consomme le contrat Ormuz et reçoit des événements de la plateforme.

Le pattern

Système métier
api_in
event_out
Ormuz

Le système métier appelle Ormuz via api_in ; Ormuz lui renvoie les événements autorisés via event_out.

Dans ces deux directions, le contrat de transport est Ormuz-owned. Les credentials correspondants sont émis et gérés par la plateforme, pas par du behavior plugin arbitraire.

Déclarer l’API entrante

Déclarez ce channel sous spec.channels dans extension.yaml :

YAML
spec:
  channels:
    - kind: api_in
      permissions:
        - company:read
        - order:read

La permission est une allowlist explicite. Une extension de type host connector ne doit pas demander des droits “au cas où” : chaque ajout augmente le contrat de confiance et doit correspondre à un cas d’intégration concret.

Déclarer les événements sortants

YAML
spec:
  channels:
    - kind: event_out
      target_url_field: webhook_target_url
      event_types:
        - order.created
        - order.updated

event_types ne peut contenir que des événements canoniques réellement livrables par webhook. Le champ URL ciblé doit être un champ de configuration de type url rattaché au channel event_out.

Rester minimal

API permissions, mappings et autorité métier sont trois choses différentes. Une permission order:write ne rend pas légitime n’importe quelle mutation de commande ; les règles d’autorité continuent de s’appliquer. Voir Autorité métier.