Channels and authentication
A channel describes an exchange between Ormuz and the partner system. The mechanism and direction determine who owns the contract, who provides the secret, and which endpoint must know the other's URL.
The four-channel matrix
| Channel | Initiateur | Reference contract | Example role |
|---|---|---|---|
api_out | Ormuz | Partner API | Ormuz calls a PSP, KYC API, or data service. |
api_in | Partenaire | API Ormuz | An ERP or business system calls an Ormuz surface granted to the extension. |
event_in | Partenaire | Partner event/webhook | The partner pushes to Ormuz a change that occurred in its system. |
event_out | Ormuz | Ormuz event | Ormuz pushes platform events to a partner endpoint. |
An extension may declare the channels it needs; it does not need to cover all four cases. The V1 contract accepts at most one channel of each type per extension.
Who owns the contract?
The rule is simple: the contract owner is the source of the mechanism.
- for an API, the server hosting the API defines the contract;
- for an event, the emitter defines the event type and its envelope;
- adapting a partner contract into an Ormuz object or event does not automatically transfer business authority.
Secrets and endpoints
| Channel | Secret | URL |
|---|---|---|
api_out | The partner issues the credential that Ormuz holds to call its API. | Ormuz knows the partner endpoint. |
api_in | Ormuz issues the credential granted to the extension. | Ormuz exposes the API consumed by the partner. |
event_in | The partner provides the secret required to verify inbound events when its contract requires one. | Ormuz expose l’endpoint d’ingestion. |
event_out | Ormuz issues the secret that lets the partner verify received events. | The partner provides a target URL to Ormuz. |
Never copy a secret issued by Ormuz into extension.yaml or any other discovery metadata. Secrets belong to the configuration lifecycle, not to the public manifest.
Rules by channel
api_in
Explicitly declare the minimum required permissions. A permission available on the platform does not need to be requested if the integration does not use it.
event_out
Declare the event types that can actually be delivered and the configuration field that contains the target URL. This field must be a URL, not a free-form string.
event_in
Validate authenticity and normalize the event according to the external contract before exposing it as an extension event. An inbound event is not an automatic right to mutate a platform object.
api_out
Credentials provided by the merchant must remain confined to the relevant channel. Dynamic options that depend on an external service are attached to that capability rather than to generic network access.