noCV
BAPIHOOK-104 · Deliver predictably

Sign exact webhook bytes with versioned verification metadata

Practice briefTaskIntermediate

Partners cannot verify signatures after the sender serializes the same event differently on retry.

Focused work estimate
2h 30m + prerequisites
Priority in the scenario
High
Engineering practice
Webhook security

Estimated field mix

  • Security70%
  • API design30%

Field percentages are editorial estimates of the ticket's engineering focus. They total 100%; they are not measured time, proficiency scores, or ownership evidence.

Your next step

Review it, then add it to your workspace.

The board opens an editable draft; nothing is saved until you confirm it. Sign-in and workspace permissions apply, and Demo boards remain ephemeral.

Project context

A fictional logistics platform sends shipment events to partner endpoints. Partners need stable schemas and recovery semantics despite duplicate delivery, failures, and subscription changes.

Setup prerequisites

  • Create a local webhook sender and receiver doubles with synthetic shipment events and disposable signing keys.

Preceding work

Complete these dependencies, or supply their agreed outputs before taking this ticket.

Acceptance criteria

  • Sign the exact delivered bytes.
  • Include key identity and bounded timestamp semantics.
  • Document receiver verification before payload trust.

Implementation constraints

  • Use generated test keys and never log signing material.

Verification to include

  • Verify a valid local delivery.
  • Change one byte or timestamp and reject verification.

Deliverables

  • Signing contract and receiver example.

Rollout and recovery

Introduce a versioned signature format with a bounded rotation overlap.

Value of the work

For the engineer: Practice public event contracts, delivery guarantees, and partner recovery workflows.

For the team: Provide inspectable asynchronous integration behavior with controlled retries and clear compatibility.

Evidence boundaries

Outcome Evidence: Tests, patches, and runbooks are requested deliverables. They become Outcome Evidence only through a qualified Mission and immutable Evidence IDs.

Ownership Evidence: Independent adaptation must be observed under a declared verification policy and cite immutable Evidence IDs. Completing a planning ticket establishes no Ownership Evidence.