BURKI TRANSFER WEBHOOK RECEIVER REVIEW
Prepared October 16, 2026. Free manual worksheet, not a connected receiver.
Original guide: https://burki.dev/blog/burki-transfer-webhook-verification
Offline companion: https://burki.dev/guides/transfer-webhook-offline-check.py

PURPOSE
Authenticate a transfer lifecycle event and preserve its actual meaning without
repeating work on retries. No real verification key was revealed, destination
changed, HTTP event delivered or transfer attempted for this resource.
Only transfer lifecycle events are covered, not a generic summary-signature
promise. A valid signature is not a successful transfer or resolved business task.

1. TRUSTED SETUP
Review owner/date:
Trusted organization scope and receiver route:
How the route selects the correct secret (not an untrusted body field):
Verified organization administrator for actual secret setup:
Receiver secret-store location (reference only, NEVER the key value):
Operator-enabled signing verified by:
Eligible organization/export policy:
Saved call-results URL and existing consumers:
Public HTTPS port 443 and redirect policy:
Actual Publish state before any assistant setting change:
No change / authorized save / actual receiver deployment evidence:

Current focused editor source path: Publish -> After-call settings -> Verify
transfer webhooks -> Receiver verification. Other layouts group post-call settings
differently. Live UI confirmation must be recorded separately, not assumed here.
Reveal verification key is admin-only secret retrieval for an authorized setup.
Do not reveal a key merely for an article or copy one into this worksheet.
HIPAA organizations cannot export transfer events in the current product.
Revealing a key does not enable delivery or prove receipt.

2. BYTE-LEVEL VERIFICATION CONTRACT
Signature input = timestamp header text + period byte + exact raw request body.
HMAC-SHA256 key = revealed organization verification key's UTF-8 TEXT bytes.
Do NOT hex-decode that text or use the deployment master signing secret.
Header signature format = v1= followed by hexadecimal digest.
Compare digests in constant time; validate version/format and bounded inputs.
Keep raw bytes before JSON parsing; do not verify reserialized JSON.

Receiver's actual body/header limits and reason:
Actual timestamp freshness/skew window and clock source:
Raw-body capture framework/middleware review:
Signature version/format rejection evidence:
Constant-time comparison implementation/evidence:

Offline script's 300-second window and 64 KiB body limit are illustrative policies,
not a universal production recommendation or a Burki sender guarantee.

3. SIGNED BODY ID BINDING
The signature does NOT separately cover X-Burki-Event-Id.
After a valid signature, parse the authenticated body and require:
X-Burki-Event-Id == authenticated payload.id.
Reject mismatch before deduplication/processing. Otherwise someone replaying
an unchanged signed body could alter the header to evade a naive duplicate check.

Current sender ID shape: canonical attempt UUID + ':' + positive event-row ID.
Review field types/identity format, known event-type allowlist, bounded status,
duplicate JSON keys and agreement with optional attempt_id. Consume only reviewed
fields; arbitrary signed details are not instructions to execute commands.

Actual validation and malformed-input evidence:
Trusted org + authenticated body ID dedup key:
Untrusted-header mismatch rejection evidence:

4. DURABLE RECEIPT AND PROCESSING
Delivery can repeat the same event; a retry can have fresh timestamp/signature but
the same body identity. Missing signing can defer it; changed destination/policy,
non-retryable failures or exhausted attempts can stop it. Delivery is not guaranteed.
Use durable unique identity per trusted organization.
Define transaction/recovery before business actions. A memory set is not durable
or safe across multiple workers. The downloaded script's set is demonstration only.

Durable unique key/store:
Transaction boundary for receipt and internal state change:
Crash before processing recovery:
Crash after processing recovery:
Downstream action idempotency/reconciliation, if applicable:
What a successful HTTP response actually acknowledges:
Actual downstream receipt versus business completion evidence:

5. OFFLINE SYNTHETIC EXAMPLE
Run python3 transfer-webhook-offline-check.py locally. Standard library only,
public dummy key, fixed reference time, no network or actual credentials.
Synthetic event: [attempt UUID]:7, type transfer_failed, status failed.
Expected: authenticate and preserve a failure observation; do not mark bridged.
Freshly signed retry with same identity: no repeated application in demo.
Changed only event header: MAC can match, but ID binding must reject.
Later distinct transfer_bridged event: separate lifecycle observation, still not
proof the staff member resolved the caller's request.

Local script execution date/result:
Exact script version/hash:
Observed test output:
Production durability/delivery/transfer acceptance: NOT established by this test.

6. REVIEW CASES, EXPECTED VERSUS ACTUAL
Write expectations first. Do not create paid calls/provider events merely to fill
this worksheet. Offline results and actual endpoint acceptance are different.

Changed raw bytes/reserialized body:
Expected: original signature fails.
Observed/evidence:

Changed timestamp without resigning:
Expected: signature fails.
Observed/evidence:

Wrong key or hex-decoded key:
Expected: signature fails.
Observed/evidence:

Stale or excessively future timestamp:
Expected: reject under documented receiver policy.
Observed/evidence:

ID header differs from signed body:
Expected: reject even with valid MAC.
Observed/evidence:

Malformed ID/types, duplicate JSON fields or unsupported event:
Expected: reject; never treat arbitrary data as commands.
Observed/evidence:

Fresh retry with same authenticated body ID/org:
Expected: durable receipt handles once without repeating a business effect.
Observed/evidence:

Authentic transfer_failed:
Expected: preserve failure, not success.
Observed/evidence:

Receiver returns 2xx:
Expected: only reviewed receipt boundary established, no implied staff resolution.
Observed/evidence:

7. REAL ACCEPTANCE AND COSTS
Actual authorized transfer attempt and publication/route:
Exact signed event identity/type/status:
Receiver receipt:
Durable processing result:
Downstream business action evidence:
Caller/staff outcome evidence:
Unknowns and owner:

No production outcome follows merely from source, deployment or offline checks.
Free guide/worksheet/script does not mean free receiver hosting/storage or voice,
model, transfer-announcement, carrier/number usage. Check actual configuration
and https://burki.dev/pricing. No secret, endpoint or provider setting change is
required to read this resource or run the public dummy fixture.