Rhythm 2.0 Specifications

Appearance

ATS-PFM-INT-013Retain and verify incoming provider notifications: Capability Test Specification

Markdown

ATS-PFM-INT-013

Retain and verify incoming provider notifications: Capability Test Specification

Markdown
  • DocumentProposed

Planning

Proves capability
CAP-PFM-INT-013

Design

Executed by
TST-PFM-INT-480, TST-PFM-INT-491, TST-PFM-INT-567, TST-PFM-INT-568, TST-PFM-INT-584

KindAcceptance test setProduct areaPlatformModuleIntegration access, customer extensions and shared workflow configurationRevision3

Read atservices-platform ad3f6a65macroservice-libraries 54536a44react-console baf6dae3

Retain and verify incoming provider notifications: Capability Test Specification ​

Coverage ​

RuleProved By
BR-CAP-PFM-INT-013-01ATS-PFM-INT-013-01
BR-CAP-PFM-INT-013-02ATS-PFM-INT-013-02
BR-CAP-PFM-INT-013-03FND-PFM-INT-076
BR-CAP-PFM-INT-013-04ATS-PFM-INT-013-03, ATS-PFM-INT-013-10, ATS-PFM-INT-013-11
BR-CAP-PFM-INT-013-05ATS-PFM-INT-013-04, ATS-PFM-INT-013-10
BR-CAP-PFM-INT-013-06ATS-PFM-INT-013-05, ATS-PFM-INT-013-09, ATS-PFM-INT-013-12, ATS-PFM-INT-013-13
BR-CAP-PFM-INT-013-07ATS-PFM-INT-013-06, ATS-PFM-INT-013-09
BR-CAP-PFM-INT-013-08ATS-PFM-INT-013-07
BR-CAP-PFM-INT-013-09ATS-PFM-INT-013-08

Provider notifications become application events only after verification and processing. The interaction cases follow valid, tampered, repeated and replayed messages through downstream routing, keeping message recovery separate from duplicate provider-event handling.

The structured scenarios name the capabilities and rules involved. A bound test contributes only the outcomes it asserts; proposed transition matrices and composed interactions still require executable proof.

Coverage

  • Rule covered
  • Transition covered
  • Validation gap: FND-PFM-INT-076
  • Permission covered
  • Edge gap: FND-PFM-INT-076
  • Failure covered
  • Boundary covered
  • Concurrency covered
  • Invariant covered
  • Interaction covered

Test Scenarios

13 scenarios proving CAP-PFM-INT-013; 7 bound to an existing test.

01 Ingress refuses invalid endpoints and overloadboundaryapinegativetest
Proves
BR-CAP-PFM-INT-013-01
Preconditions
Prepare enabled, disabled and unknown endpoints.
Steps
Post ordinary messages, an oversized body and traffic above the endpoint limit.
Expected
Only the enabled endpoint records ordinary messages; invalid endpoints return empty not-found, oversized input refuses and overload is throttled.
Data
Fixtures establishing the stated accounts, declarations and history in an isolated workspace.
Bound to
Source
services-platform:modules/integrations/tests/integration/services/webhooks/ingress.integration.spec.js#answers 404 for a disabled endpoint, and records nothing
02 Durable notification storage precedes acknowledgementinvariantapitest
Proves
BR-CAP-PFM-INT-013-02
Preconditions
An enabled endpoint receives ordinary authentication headers and cookies.
Steps
Post a notification and inspect stored material and dispatch.
Expected
Sensitive headers are omitted, the pending event has its digest and queued work, and receipt is acknowledged afterwards.
Data
Fixtures establishing the stated accounts, declarations and history in an isolated workspace.
Bound to
Source
services-platform:modules/integrations/tests/integration/services/webhooks/ingress.integration.spec.js#stores the body and headers, then records the event pending and queued with its digest and a queue row
03 Signature checks precede event productionfailureapinegativetest
Proves
BR-CAP-PFM-INT-013-04
Preconditions
Prepare valid, tampered and excessively old signatures.
Steps
Process them and repeatedly fail processing of a retryable message.
Expected
Valid input produces a routed event, invalid signatures produce none and repeated retryable failure becomes dead at six attempts.
Data
Fixtures establishing the stated accounts, declarations and history in an isolated workspace.
Bound to
Source
services-platform:modules/integrations/tests/integration/services/webhooks/webhook-worker.integration.spec.js#rejects a request whose signature does not verify, writing no event
04 Deduplication does not prevent explicit replayconcurrencyapitest
Proves
BR-CAP-PFM-INT-013-05
Preconditions
Processed notifications exist with and without provider identifiers.
Steps
Resubmit both and explicitly replay the identified message.
Expected
Repeated notifications are retained, then marked ignored with the earlier message identified and no new emitted event; explicit replay processes again and emits new events.
Data
Fixtures establishing the stated accounts, declarations and history in an isolated workspace.
Bound to
Source
services-platform:modules/integrations/tests/integration/services/webhooks/webhook-worker.integration.spec.js#ignores a second request with the provider event id of one already processed, pointing at the first
05 Manual setup reveals its secret onceruleapitest
Proves
BR-CAP-PFM-INT-013-06
Preconditions
Verification has provisioned a manually registered endpoint.
Steps
Read endpoint setup twice as an administrator.
Expected
Initial setup returns address and signing secret; the later read retains the address only.
Data
Fixtures establishing the stated accounts, declarations and history in an isolated workspace.
Bound to
Source
services-platform:modules/integrations/tests/e2e-adapters/events-dummy.adapters.spec.js#never answers the secret again
06 Rotation retains the previous signature temporarilytransitionapitest
Proves
BR-CAP-PFM-INT-013-07
Preconditions
The endpoint is in its signing-secret overlap window.
Steps
Process a message signed by the previous secret.
Expected
Verification accepts it during the rotation window.
Data
Fixtures establishing the stated accounts, declarations and history in an isolated workspace.
Bound to
Source
services-platform:modules/integrations/tests/integration/services/webhooks/webhook-worker.integration.spec.js#verifies with the previous secret too while the endpoint rotates
07 Replay limits bound recovery workboundaryapiproposed
Proves
BR-CAP-PFM-INT-013-08
Preconditions
Stored endpoint messages span ten days.
Steps
Replay one, request seven- and eight-day windows and request replay as a reader.
Expected
Individual and permitted-window requests queue audited replay; the larger window and unauthorized caller refuse.
Data
Fixtures establishing the stated accounts, declarations and history in an isolated workspace.
Source
services-platform:docs/integrations/README.md#Webhooks (WS8, 2026-10-18)
08 Readers cannot consume the one-time secretpermissionapitest
Proves
BR-CAP-PFM-INT-013-09
Preconditions
A reader can inspect an endpoint whose setup secret has not been read.
Steps
Inspect every permitted endpoint and notification read.
Expected
No secret returns and the administrator’s initial disclosure remains available.
Data
Fixtures establishing the stated accounts, declarations and history in an isolated workspace.
Bound to
Source
services-platform:modules/integrations/tests/e2e/reader-access.e2e.spec.js#reads no webhook signing secret in any answer
09 Exercise the complete webhook endpoint secret lifecycletransitionapinegativeproposed
Proves
BR-CAP-PFM-INT-013-06 BR-CAP-PFM-INT-013-07 BR-CAP-PFM-INT-004-09
Preconditions
Prepare one independent record in each starting state, including absent-record cases where the model defines creation.
Steps
Run each listed transition once with its guard satisfied, then repeat it with the guard denied. Inspect the resulting record and listed side effects after commit.
Expected
Each positive case reaches its listed destination and records its defined side effects. Each denied case preserves the starting record and creates no transition side effects.
Data
Run-owned records and principals in an isolated workspace.
Source
rhythm-v2-docs:specs/platform/integrations/design/state-models/STATE-PFM-INT-005-webhook-endpoint-secret-lifecycle.md#transitions
10 Exercise the complete received provider message processingtransitionapinegativeproposed
Proves
BR-CAP-PFM-INT-013-04 BR-CAP-PFM-INT-013-05
Preconditions
Prepare one independent record in each starting state, including absent-record cases where the model defines creation.
Steps
Run each listed transition once with its guard satisfied, then repeat it with the guard denied. Inspect the resulting record and listed side effects after commit.
Expected
Each positive case reaches its listed destination and records its defined side effects. Each denied case preserves the starting record and creates no transition side effects.
Data
Run-owned records and principals in an isolated workspace.
Source
rhythm-v2-docs:specs/platform/integrations/design/state-models/STATE-PFM-INT-009-received-provider-message-processing.md#transitions
11 Verified notifications become routed eventsinteractionapiproposed
Proves
BR-CAP-PFM-INT-013-04 BR-CAP-PFM-INT-015-02
Preconditions
A provisioned endpoint and matching application consumer are available.
Steps
Process a valid notification, route its emitted event, then process a tampered notification.
Expected
The valid message reaches its consumer; signature refusal emits no event.
Data
Run-owned records and principals in an isolated workspace.
Source
services-platform:modules/integrations/tests/integration/services/webhooks/webhook-worker.integration.spec.js#rejects a request whose signature does not verify, writing no event,services-platform:modules/integrations/services/events/event-router.ts:routeIntegrationEvents
12 Verification provisions notification endpointsinteractionapiproposed
Proves
BR-CAP-PFM-INT-004-05 BR-CAP-PFM-INT-013-06
Preconditions
A release declares a manually registered notification endpoint.
Steps
Complete account verification, read setup once and inspect the ordinary endpoint read.
Expected
The account activates, setup exposes its provisioned address and secret once, and later inspection omits the secret.
Data
Run-owned records and principals in an isolated workspace.
Source
services-platform:modules/integrations/tests/integration/services/connections/connection-jobs.integration.spec.js#becomes active with the account and every declared feature verified,services-platform:modules/integrations/tests/e2e-adapters/events-dummy.adapters.spec.js#never answers the secret again
13 Credential verification establishes endpoint setupinteractionapiproposed
Proves
BR-CAP-PFM-INT-005-05 BR-CAP-PFM-INT-013-06
Preconditions
An initial key account declares a manual endpoint.
Steps
Enter valid credentials, finish verification and inspect endpoint setup twice.
Expected
The verification job activates the account and provisions its endpoint; ordinary reads reveal no signing secret.
Data
Run-owned records and principals in an isolated workspace.
Source
services-platform:modules/integrations/services/credentials/credential-store.ts:verification_retried,services-platform:modules/integrations/tests/e2e-adapters/events-dummy.adapters.spec.js#never answers the secret again

The Markdown files under specs/ in rhythmsoftware/rhythm-v2-docs are the canonical source of truth. This reader is a generated, read-only projection of them.

Rhythm Software