|
| 1 | +# Bridge Adapter Outcome Contract |
| 2 | + |
| 3 | +Bridge adapters are bounded ingress or handoff surfaces. They translate one |
| 4 | +authenticated integration event into a workflow start, signal, update, or |
| 5 | +bounded external-task handoff. They do not replay workflows, interpret event |
| 6 | +history, or own workflow state transitions. |
| 7 | + |
| 8 | +The authoritative machine-readable contract is published from |
| 9 | +`GET /api/cluster/info` at `bridge_adapter_outcome_contract`: |
| 10 | + |
| 11 | +- `schema: durable-workflow.v2.bridge-adapter-outcome.contract` |
| 12 | +- `version: 1` |
| 13 | +- `boundary` |
| 14 | +- `patterns` |
| 15 | +- `idempotency` |
| 16 | +- `visibility` |
| 17 | +- `outcomes` |
| 18 | +- `rejection_reasons` |
| 19 | +- `reference_journeys` |
| 20 | + |
| 21 | +## Webhook Receiver |
| 22 | + |
| 23 | +The first runtime bridge endpoint is: |
| 24 | + |
| 25 | +```text |
| 26 | +POST /api/bridge-adapters/webhook/{adapter} |
| 27 | +``` |
| 28 | + |
| 29 | +The route is protected by the same control-plane version, auth, and namespace |
| 30 | +middleware as other API routes. `{adapter}` is an operator-visible adapter key |
| 31 | +made of letters, numbers, `.`, `_`, `:`, or `-`. |
| 32 | + |
| 33 | +Every request must include: |
| 34 | + |
| 35 | +```json |
| 36 | +{ |
| 37 | + "action": "start_workflow | signal_workflow | update_workflow", |
| 38 | + "idempotency_key": "provider-event-id", |
| 39 | + "target": {}, |
| 40 | + "input": {}, |
| 41 | + "correlation": {} |
| 42 | +} |
| 43 | +``` |
| 44 | + |
| 45 | +`input` and `correlation` are optional. The response never echoes raw provider |
| 46 | +payloads, authorization material, signatures, tokens, or secrets. |
| 47 | + |
| 48 | +## Reference Journey: Incident Event Signals A Workflow |
| 49 | + |
| 50 | +Use this journey when an incident, alerting, or ticketing system needs to wake |
| 51 | +an existing remediation workflow. |
| 52 | + |
| 53 | +```json |
| 54 | +{ |
| 55 | + "action": "signal_workflow", |
| 56 | + "idempotency_key": "pagerduty-event-3003", |
| 57 | + "target": { |
| 58 | + "workflow_id": "wf-remediation-42", |
| 59 | + "signal_name": "incident_escalated" |
| 60 | + }, |
| 61 | + "input": { |
| 62 | + "severity": "critical", |
| 63 | + "service": "checkout" |
| 64 | + }, |
| 65 | + "correlation": { |
| 66 | + "provider": "pagerduty", |
| 67 | + "event_type": "incident.triggered" |
| 68 | + } |
| 69 | +} |
| 70 | +``` |
| 71 | + |
| 72 | +Expected outcomes: |
| 73 | + |
| 74 | +- first delivery: HTTP 202, `outcome: accepted` |
| 75 | +- redelivery with the same adapter, idempotency key, workflow id, and signal |
| 76 | + name: HTTP 200, `outcome: duplicate`, |
| 77 | + `control_plane_outcome: deduped_existing_command` |
| 78 | +- missing workflow: HTTP 422, `outcome: rejected`, `reason: unknown_target` |
| 79 | +- malformed target: HTTP 422, `outcome: rejected`, `reason: malformed_payload` |
| 80 | + |
| 81 | +The accepted command context records `adapter`, `action`, `idempotency_key`, |
| 82 | +`request_id`, and `signal_name`. |
| 83 | + |
| 84 | +## Reference Journey: Commerce Event Starts A Workflow |
| 85 | + |
| 86 | +Use this journey when a commerce or SaaS integration receives a provider event |
| 87 | +that should start one durable workflow. |
| 88 | + |
| 89 | +```json |
| 90 | +{ |
| 91 | + "action": "start_workflow", |
| 92 | + "idempotency_key": "stripe-event-1001", |
| 93 | + "target": { |
| 94 | + "workflow_type": "orders.fulfillment", |
| 95 | + "task_queue": "external-workflows", |
| 96 | + "business_key": "order-1001", |
| 97 | + "duplicate_policy": "use_existing" |
| 98 | + }, |
| 99 | + "input": { |
| 100 | + "order_id": "order-1001" |
| 101 | + }, |
| 102 | + "correlation": { |
| 103 | + "provider": "stripe", |
| 104 | + "event_type": "checkout.session.completed" |
| 105 | + } |
| 106 | +} |
| 107 | +``` |
| 108 | + |
| 109 | +Expected outcomes: |
| 110 | + |
| 111 | +- first delivery: HTTP 202, `outcome: accepted`, |
| 112 | + `control_plane_outcome: started_new` |
| 113 | +- redelivery while the workflow is still active: HTTP 200, |
| 114 | + `outcome: duplicate`, `reason: duplicate_start`, |
| 115 | + `control_plane_outcome: returned_existing_active` |
| 116 | +- unconfigured workflow type: HTTP 422, `outcome: rejected`, |
| 117 | + `reason: unknown_target` |
| 118 | +- unsupported action: HTTP 422, `outcome: rejected`, |
| 119 | + `reason: unsupported_action` |
| 120 | + |
| 121 | +When no explicit `workflow_id` is supplied, the server derives a stable |
| 122 | +`bridge-{adapter}-{hash}` workflow id from the adapter and idempotency key. |
| 123 | + |
| 124 | +## Outcome Shape |
| 125 | + |
| 126 | +All bridge responses include the contract identity: |
| 127 | + |
| 128 | +```json |
| 129 | +{ |
| 130 | + "schema": "durable-workflow.v2.bridge-adapter-outcome.contract", |
| 131 | + "version": 1, |
| 132 | + "adapter": "stripe", |
| 133 | + "action": "start_workflow", |
| 134 | + "accepted": true, |
| 135 | + "outcome": "accepted", |
| 136 | + "idempotency_key": "stripe-event-1001", |
| 137 | + "target": { |
| 138 | + "workflow_type": "orders.fulfillment", |
| 139 | + "task_queue": "external-workflows", |
| 140 | + "business_key": "order-1001" |
| 141 | + }, |
| 142 | + "workflow_id": "bridge-stripe-...", |
| 143 | + "run_id": "..." |
| 144 | +} |
| 145 | +``` |
| 146 | + |
| 147 | +`target` is a redacted, operator-safe target summary. It may include workflow |
| 148 | +id, workflow type, signal name, update name, task queue, and business key. It |
| 149 | +must not include raw provider payloads or credential material. |
0 commit comments