Integration Contract¶

Reference for the integration communication contract. This covers the interface every platform integration must implement, the request/response DTOs, and the exceptions. The contract covers connection verification (CFX-53), outbound bulk exports (CFX-45), and inbound webhook processing (CFX-48).

Interface: IntegrationContract¶

Namespace: App\Contracts\IntegrationContract

interface IntegrationContract {}

Marker interface with no methods of its own. Every registered integration implements it, but the interface declares no capability — verification, bulk export, webhooks, and on-demand consent pull are all optional per integration and live on separate Can* interfaces instead; see Optional Capability Interfaces below. This is the same pattern App\Contracts\HasConnectionConfiguration already uses.

Abstract Base Class: AbstractIntegration¶

Namespace: App\Services\AbstractIntegration

Implements IntegrationContract. Concrete integrations extend this class. Its constructor is the only thing it provides directly — the toolkit every integration needs regardless of which capabilities it opts into:

public function __construct(
    protected readonly CircuitBreaker $circuitBreaker = new CircuitBreaker,
    protected readonly ConnectionTokenIssuerService $connectionTokenIssuerService = new ConnectionTokenIssuerService,
) {}

It does not inject ConsentRecorder. Integrations produce ConsentData and hand it upwards; persisting it is the transformer's job, and AbstractTransformer injects its own instance. An integration that ever needs to write consent directly injects ConsentRecorder in its own constructor rather than taking it from the base class — PrestaShopIntegration does exactly that for its consent webhook.

The reasoning behind this split — why the contract is a marker and capabilities are opt-in — is recorded in ADR-0023.

AbstractIntegration declares no capability methods of its own. Each capability — verification, bulk export, webhooks, on-demand consent pull, deletion log — is implemented by a dedicated trait in App\Services\Concerns, which a concrete integration pulls in with use alongside the matching Can* interface:

Every trait is constrained with @phpstan-require-extends AbstractIntegration — it can only be use-d on a class extending AbstractIntegration, since it reads $this->circuitBreaker — and declares its public method(s) final, so concrete integrations never override verify(), requestBulkExport(), streamBulkExport(), probeBulkExport(), fetchBulkExportPageRange(), transformerClass(), handleWebhook(), pullConsent(), or fetchDeletionLog() directly; they only implement the perform*()/process*()/provide*() hook the trait requires. The bulk-export, webhook, consent-pull, and deletion-log traits wrap their hook in the same error-handling strategy: any Throwable that is not already an IntegrationRequestException is caught and re-thrown as InvalidIntegrationResponseException. VerifiesConnections uses a different strategy — see CanVerifyConnections below.

performVerification() (required by VerifiesConnections)¶

abstract protected function performVerification(SystemConnection $connection): VerificationResult;

Declared abstract on the VerifiesConnections trait, so it must be implemented by any integration that uses the trait (and, correspondingly, declares implements CanVerifyConnections). It performs the integration-specific credential check against the live system and resolves the external user/account identifier consumed by the Connection Flow. Return VerificationResult::success($externalUserId) on success. On failure, either return VerificationResult::failure($message) explicitly, or simply throw — verify() catches any Throwable and converts it into a failed VerificationResult, so an integration can rely on $response->throw() as its failure path without any local try/catch.

fetchBulkExportBatches() (required by ExportsInBulk)¶

/** @param Closure(Collection<int, DomainRecord>): void $onBatch */
abstract protected function fetchBulkExportBatches(SystemConnection $connection, ExportRequest $request, Closure $onBatch): void;

Declared abstract on the ExportsInBulk trait — implement it, alongside provideTransformerClass(), to support bulk export. It fetches records from the external system in pages, calling $onBatch once per non-empty page — page size and pagination strategy are entirely up to the integration. Called by streamBulkExport()/requestBulkExport(). Only integrations that support bulk export need to use ExportsInBulk and implement it — and must additionally declare implements CanExportInBulk (see below) so callers can discover the capability via instanceof.

provideTransformerClass() (required by ExportsInBulk)¶

/** @return class-string<TransformerContract> */
abstract protected function provideTransformerClass(): string;

Declared abstract on the ExportsInBulk trait, alongside fetchBulkExportBatches(), returning the AbstractTransformer subclass responsible for persisting the DTOs this integration produces. Backs the public, sealed transformerClass().

performProbeBulkExport() (virtual, optional)¶

protected function performProbeBulkExport(SystemConnection $connection, ExportRequest $request): BulkExportProbe;

Declared with a default body on the ExportsInBulk trait — override it to report the total page count and page size without fetching any records, enabling BulkSyncJob to fan out parallel fetchBulkExportPageRange() jobs. The default returns new BulkExportProbe(totalPages: 1, perPage: 0), so performFetchBulkExportPageRange() falls back to a single fetchBulkExportBatches() call.

performFetchBulkExportPageRange() (virtual, optional)¶

/** @param Closure(Collection<int, DomainRecord>): void $onBatch */
protected function performFetchBulkExportPageRange(SystemConnection $connection, ExportRequest $request, int $startPage, int $endPage, int $perPage, Closure $onBatch): void;

Declared with a default body on the ExportsInBulk trait — override alongside performProbeBulkExport() to fetch a specific page range, calling $onBatch once per page. The default ignores the range and delegates to fetchBulkExportBatches(), which is correct for integrations whose probe always returns a single page.

processWebhook() (required by HandlesWebhooks)¶

/** @param array<string, mixed> $payload */
abstract protected function processWebhook(SystemConnection $connection, array $payload): void;

Declared abstract on the HandlesWebhooks trait. Implement it to handle inbound webhooks. Only integrations that receive webhooks need to use HandlesWebhooks and implement it — and must additionally declare implements CanHandleWebhooks (see below) so callers can discover the capability via instanceof.

performPullConsent() (required by PullsConsent)¶

abstract protected function performPullConsent(SystemConnection $connection, string $customerSourceId): ?ConsentData;

Declared abstract on the PullsConsent trait. Implement it to read a contact's current consent state from the external system. Return null when the contact exists but has no consent state recorded. Throw ConsentTargetNotFoundException when $customerSourceId is unknown to the target system. Only integrations that support reading consent on demand need to use PullsConsent and implement it — and must additionally declare implements CanPullConsent (see below) so callers can discover the capability via instanceof.

performFetchDeletionLog() (required by FetchesDeletionLog)¶

protected function performFetchDeletionLog(SystemConnection $connection, SystemCapability $capability, ?string $since): Collection;

Declared abstract on the FetchesDeletionLog trait. Implement it to fetch the platform's log of records deleted for the given capability since the given cursor ($since, an ISO 8601 string, or null for the platform's full deletion history). Only integrations that support a deletion log need to implement it — and must additionally use FetchesDeletionLog and declare implements HasDeletionLog (see below) so callers can discover the capability via instanceof. See Deletion Log Sync for how $since is derived (it reuses the same delta cursor as ExportRequest::$modifiedAfter) and how the returned entries are consumed.

Optional Capability Interfaces¶

Some capabilities are genuinely optional — only some integrations support them — so they live on small, separate interfaces instead of bloating IntegrationContract. This is the same pattern App\Contracts\HasConnectionConfiguration already uses: callers check instanceof before calling, e.g. WidgetConfigurationController and SystemConnectionObserver check instanceof HasConnectionConfiguration and skip otherwise. Each interface below is backed by a paired trait in App\Services\Concerns (see Abstract Base Class: AbstractIntegration) that provides the final public method(s); a concrete integration opts in by use-ing the trait, implementing the corresponding perform*()/process*()/provide*() hook(s), and declaring the interface. HasConsentChannels is the exception: it declares static facts about the platform rather than an outbound operation, so there is no circuit breaker or error translation to wrap and no backing trait — an integration implements its one method directly.

CanVerifyConnections¶

Namespace: App\Contracts\CanVerifyConnections

public function verify(SystemConnection $connection): VerificationResult;

• verify() — authenticates the connection's credentials against the live system and resolves the external user/account identifier. Never throws; failures are reported through the returned VerificationResult.

Checked by SystemConnectionService::verify(), which resolves the integration via IntegrationRegistry and — if it isn't an instance of CanVerifyConnections — returns VerificationResult::failure('This integration does not support verification.') instead of calling it. In practice all three registered integrations (WooCommerceIntegration, PrestaShopIntegration, UserPlatformIntegration) implement it, so this is currently a safety net rather than a path any of them hits.

CanExportInBulk¶

Namespace: App\Contracts\CanExportInBulk

public function requestBulkExport(SystemConnection $connection, ExportRequest $request): Collection;

/** @param Closure(Collection<int, DomainRecord>): void $onBatch */
public function streamBulkExport(SystemConnection $connection, ExportRequest $request, Closure $onBatch): void;

public function probeBulkExport(SystemConnection $connection, ExportRequest $request): BulkExportProbe;

/** @param Closure(Collection<int, DomainRecord>): void $onBatch */
public function fetchBulkExportPageRange(SystemConnection $connection, ExportRequest $request, int $startPage, int $endPage, int $perPage, Closure $onBatch): void;

/** @return class-string<TransformerContract> */
public function transformerClass(): string;

• requestBulkExport() — returns a Collection<int, DomainRecord> containing every fetched record. Throws IntegrationRequestException (or a subclass) on any integration-layer failure. Built on top of streamBulkExport().
• streamBulkExport() — invokes $onBatch once per fetched page, without accumulating the full result set in memory. Throws IntegrationRequestException (or a subclass).
• probeBulkExport() — returns the total page count and page size without fetching any records, so the job layer can fan out parallel fetchBulkExportPageRange() calls. Throws IntegrationRequestException (or a subclass).
• fetchBulkExportPageRange() — fetches a specific [startPage, endPage] range, invoking $onBatch once per page. Throws IntegrationRequestException (or a subclass).
• transformerClass() — returns the TransformerContract implementation responsible for persisting this integration's fetched data. Throws IntegrationRequestException (or a subclass) — same wrapping strategy as the other methods here, even though provideTransformerClass() never made an outbound call.

Checked by both BulkSyncJob and FetchBulkPageRangeJob, which resolve the integration via IntegrationRegistry and — if it isn't an instance of CanExportInBulk — skip without calling it (BulkSyncJob logs a warning and returns; FetchBulkPageRangeJob marks the connection Error and cancels its batch, matching how it already reacts to a CircuitBreakerOpenException). In practice BulkSyncJob is only ever dispatched for capabilities SystemConnection::pullInCapabilities() reports as active (admin-configured via System.capabilities/SyncRule), so today this is a safety net rather than a path either registered integration hits.

CanHandleWebhooks¶

Namespace: App\Contracts\CanHandleWebhooks

/** @param array<string, mixed> $payload */
public function handleWebhook(SystemConnection $connection, array $payload): void;

Checked by ProcessWebhookJob, which resolves the integration via IntegrationRegistry, and — if it isn't an instance of CanHandleWebhooks — logs a warning and discards the webhook instead of calling it.

CanPullConsent¶

Namespace: App\Contracts\CanPullConsent

public function pullConsent(SystemConnection $connection, string $customerSourceId): ?ConsentData;

PrestaShopIntegration calls its own pullConsent() from processWebhook() (see the PrestaShop Integration reference), using it to re-fetch a customer's authoritative consent state rather than trusting the inbound webhook payload. WooCommerceIntegration implements it too, reading the connector plugin's newsletter meta for a single contact — see WooCommerce Integration → Consent; nothing calls that one yet, the capability exists so a future caller (CFX-180) does not have to re-derive each platform's consent field. UserPlatformIntegration implements it for contacts Conflux created in the workspace only: an id the delivery ledger does not hold for the connection is refused with ConsentTargetNotFoundException before any request — see User Platform Integration → Path 1. Callers must check instanceof CanPullConsent before calling.

HasConsentChannels¶

Namespace: App\Contracts\HasConsentChannels

/** @return list<ConsentChannel> */
public function supportedConsentChannels(): array;

Declares which consent channels an integration's platform can actually represent. Channels are asymmetric across platforms — PrestaShop carries a single newsletter flag, WooCommerce has no native consent field at all, while a marketing platform may track email and SMS separately — so a propagator pushing consent outward needs to know what a target can even accept.

Outbound writers implement it too, and that is where it is consumed: App\Services\Concerns\AcceptsConsentChannels answers a writer's accepts() from the writer's own supportedConsentChannels(), so a consent on a channel the target cannot express is suppressed before any request. Nothing reads an integration's declaration yet. A future caller narrowing consents by a declaration has one rule to get right, and it is the easy one to get backwards:

WooCommerceIntegration declares [ConsentChannel::Email] (CFX-93) — one newsletter checkbox is one channel. UserPlatformIntegration declares [ConsentChannel::Email, ConsentChannel::Sms]: email is the contact's email_opt_in, SMS its suppression flag unsubscribed_from_sms, which the API accepts but never returns, so SMS is written and received by webhook but not pulled (ADR-0045). PrestaShopIntegration declares nothing; its writer declares [ConsentChannel::Email]. Tests\Support\FakeIntegration implements it (defaulting to [ConsentChannel::Email], overridable via its consentChannels constructor argument) so tests can exercise both sides.

HasFullyReportedConsentChannels¶

Namespace: App\Contracts\HasFullyReportedConsentChannels

/** @return list<ConsentChannel> */
public function fullyReportedConsentChannels(): array;

Declares the consent channels whose full state an integration reports inbound: subscriptions and withdrawals alike. On such a channel the connection's consent mirror stands for the platform's current value. A channel the integration mirrors but does not report in full is one-way. Its row is the last state seen, so it must not decide an echo or a two-way conflict. DependentEchoes asks DependentRecord::isFullyReportedBy() about the target mirror row, and treats a row that is not fully reported as absent. The admin consent view marks such a row Last reported, not live.

This is a different fact from HasConsentChannels. That interface says what a platform can represent, and writers declare it too. This one says what an integration can read back. Here too, undeclared means no claim: an integration that does not implement it is taken to report every channel in full, which is how every mirror was treated before.

UserPlatformIntegration declares [ConsentChannel::Email], because its SMS mirror only ever learns a withdrawal. WooCommerceIntegration and PrestaShopIntegration declare [ConsentChannel::Email], because their newsletter flag reads both ways (ADR-0045).

HasDeletionLog¶

Namespace: App\Contracts\HasDeletionLog

/** @return Collection<int, DeletionLogRecord> */
public function fetchDeletionLog(SystemConnection $connection, SystemCapability $capability, ?string $since): Collection;

Implemented only by integrations whose platform actually exposes a deletion log, backed by App\Services\Concerns\FetchesDeletionLog. The trait provides the final, circuit-breaker-wrapped fetchDeletionLog() and obliges the class to implement performFetchDeletionLog(). Named Has* rather than Can* because it states a fact about the platform — this shop keeps a deletion log — where the Can* interfaces name an operation the integration performs; HasConnectionConfiguration and HasConsentChannels sit on the same side of that line.

BulkSyncJob checks $integration instanceof HasDeletionLog once, right after resolving the integration for the batch, and that check gates whether FetchDeletionLogJob is dispatched at all — unlike processWebhook(), which only runs in reaction to an inbound request. An integration without a deletion log never has FetchDeletionLogJob dispatched for it in the first place; FetchDeletionLogJob itself only ever runs for a HasDeletionLog integration, a static guarantee from its sole caller that it asserts rather than re-checks.

This was a deliberate change from an earlier design that put fetchDeletionLog()/supportsDeletionLog(): bool directly on IntegrationContract, forcing every integration to carry a capability flag for something not every integration has. See Deletion Log Sync — Optional Capability via HasDeletionLog for the full rationale.

Deletion log endpoint contract¶

Every concrete HasDeletionLog integration implements performFetchDeletionLog() as an HTTP GET request following the same request/response shape — only the endpoint URL, auth, and branding differ per platform. See WooCommerce Integration — Deletion Log and PrestaShop Integration — Deletion Log for those concrete details.

Internal Consent Recorder: ConsentRecorder¶

Namespace: App\Services\ConsentRecorder

The store path of a consent mirror inside Conflux's own database: every write of a CustomerConsent row goes through it, whether the consent arrives with its customer's import or on its own by webhook. Consent is a dependent domain mirrored per connection, so a row is one connection's view of one customer's consent on one channel. The decision is recorded in ADR-0041, which supersedes ADR-0024.

It records state and nothing else. Deciding which channels a target integration can accept is a different question, answered by HasConsentChannels at the propagating caller, not here.

public function write(SystemConnection $connection, ConsentData $consent): StoreOutcome;

write() finds the connection's row by (system_connection_id, source_id), creates it if there is none, and returns what happened: Inserted, Updated or NotTouched. It applies three rules.

• A channel the source did not mention is not touched. A write names one channel through its sourceId, so the rule holds by construction.
• null never overwrites a known value. A source reports null for what it cannot know, in any value field (subscribed, confirmed, the three timestamps, source, ip_address). The one exception is a withdrawal: subscribed: false clears confirmed and confirmed_at, because they describe an opt-in that no longer exists. Kept, a later re-subscription that a shop reports with confirmed: null would inherit the old confirmation and be written to Positive User as verified, without a new double opt-in. subscribed_at stays, as the record of when the ended opt-in was given.
• A write older than the mirror is refused. Where the row already holds a consent_updated_at strictly later than the incoming consentUpdatedAt, nothing is written, the outcome is NotTouched, and a warning is logged. An equal time applies, so a same-time re-report lands. A trashed row is revived whatever its time: the trash is itself a later observation, so the time it kept is no evidence of a newer state.

The change signal. A consent moves its own content_changed_at, and only when a value field changes or a trashed row is revived. consent_updated_at moving alone does not count: WooCommerce sets it to the customer's date_modified_gmt, so counting it would move the signal on every customer edit. Linking customer_id does not count either.

Ordering within one mirror, not across writers. A mirror has exactly one writer, its own connection, so there is no ordering across writers and no written_by_system_connection_id. One source still delivers out of order: a bulk import page processed after a newer webhook, or a retried webhook after the one that followed it. The stale-write guard above orders a mirror's writes by the source's own time.

consentUpdatedAt stays required. ConsentData::$consentUpdatedAt carries the instant the source last reported this state as current. It orders the writes to one mirror, and a two-way conflict between two mirrors is settled by it, so a consent that arrives without one cannot be placed. It is a typed instant, a CarbonImmutable on the DTO and a timestamp column on the row, and a mapper reads it through SourceDateTimes like every other source datetime. SourceDateTimes returns null for a value it cannot read, and a consent with no consentUpdatedAt is omitted rather than written with a guess, the same way a channel the platform reports no signal for is. See The One Required Datetime.

Soft-deleted rows are revived, not duplicated. CustomerConsent soft-deletes while (system_connection_id, source_id) is a plain unique index, so a trashed row keeps occupying the key. write() looks the row up with withTrashed() and clears deleted_at and deletion_reason in place, the way AbstractTransformer revives a customer, and the revive counts as a change. A trashed row means the connection is in its disconnect grace period or its customer was deleted at the source (see ADR-0013), never that consent was withdrawn.

customer_id is linked where the connection mirrors the parent customer, found by parent_source_id, and left empty otherwise.

ConsentRecorder is a plain injectable class, not a Spatie\LaravelData\Data object and not part of the trait/Can* capability system above: it is never instanceof-checked. Callers receive it via constructor injection with a default value, the same "default-value" DI pattern AbstractIntegration uses for CircuitBreaker. AbstractTransformer constructor-injects ConsentRecorder $consentRecorder = new ConsentRecorder() and routes every ConsentData in store() to write(); PrestaShopIntegration injects its own for processWebhook(), which writes a single consent without a customer import.

Verification DTO: VerificationResult¶

Namespace: App\Data\VerificationResult

Plain readonly class — not a Spatie\LaravelData\Data object, so it is never serialised directly and has no SnakeCaseMapper. Construct it via the named constructors rather than new:

public static function success(string $externalUserId): self;
public static function failure(?string $message = null): self;

Request DTO: ExportRequest¶

Namespace: App\Data\ExportRequest

SystemCapability enum¶

Response DTO: BulkExportProbe¶

Namespace: App\Data\BulkExportProbe

Plain class (not a Spatie\LaravelData\Data object), returned by probeBulkExport().

Response DTOs¶

All DTOs use Spatie\LaravelData\Data and the SnakeCaseMapper — property names are camelCase in PHP and snake_case when serialised.

Monetary values (price, originalPrice, unitPrice, total, totalTax, totalShipping, totalSpent) are always integers in minor currency units (e.g. cents). A price of €12.99 is stored as 1299.

Datetime fields (createdAt, updatedAt, datePaid, subscribedAt, and so on) are ?CarbonImmutable, never strings. An integration parses them at its own boundary against a format it declares, through App\Services\SourceDateTimes, and an instant is always in UTC. dateOfBirth is a calendar date, so it is never converted. Both are nullable because an unreadable source value is nulled rather than defaulted. See ADR-0018 for the rule and Data Layer for the type convention.

CustomerData¶

Namespace: App\Data\CustomerData

ProductData¶

Namespace: App\Data\ProductData

OrderData¶

Namespace: App\Data\OrderData

Sub-DTOs¶

ConsentData¶

Namespace: App\Data\ConsentData

Despite sitting under Sub-DTOs, ConsentData is no longer nested in CustomerData: it is the canonical record of the dependent customer_consents domain and implements DomainRecord. A mapper emits it next to its customer.

AddressData¶

Namespace: App\Data\AddressData

All fields are optional (?string).

CustomAttributeData¶

Namespace: App\Data\CustomAttributeData

Represents a single platform-specific attribute. Serialises as an object in a JSON array: [{"key": "shop_id", "value": "7"}, ...].

LineItemData¶

Namespace: App\Data\LineItemData

DeletionLogRecord¶

Namespace: App\Data\DeletionLogRecord

Uses Spatie\LaravelData\Data and the SnakeCaseMapper, like the other response DTOs. Represents a single record deleted on the source platform, as returned by fetchDeletionLog(). See Deletion Log Sync for how entries are matched to local records.

Enums¶

SystemDriver¶

Gender¶

ProductStatus¶

ConsentChannel¶

Implements App\Contracts\HasLabel; label() returns the display name below.

Consent is tracked per channel: customer_consents is unique on (system_connection_id, source_id) with source_id = {parent_source_id}:{channel}, and a mapper emits one ConsentData per channel its source reports after the CustomerData (see Transformer Contract). A source that only knows one channel emits a single consent; channels it says nothing about keep whatever state another system recorded — see Missing information is not a withdrawal.

ConsentSource¶

DeletionLogEntityType¶

The entity_type value a HasDeletionLog integration sends to and reads from a platform's deletion-log endpoint. SystemCapability::deletionLogEntityType() maps each capability to its case — singular wire values, unlike SystemCapability's own plural backing values.

IntegrationRegistry¶

Namespace: App\Services\IntegrationRegistry

A singleton that maps each SystemDriver to a concrete integration class. It is the only mechanism by which Conflux locates the correct integration at runtime — no integration class is referenced directly outside of AppServiceProvider.

public function register(SystemDriver $driver, string $integration): void
public function resolve(SystemDriver $driver): IntegrationContract

• register() — associates a SystemDriver case with a class-string<IntegrationContract>. By convention, every integration is registered directly in App\Providers\AppServiceProvider::boot() — there is no per-integration service provider.
• resolve() — returns an instance of the registered integration, resolved via the service container (app($class)). Throws RuntimeException if no integration has been registered for the given driver.

The registry itself is bound as a singleton in AppServiceProvider::register():

$this->app->singleton(IntegrationRegistry::class);

Because it is a singleton, all register() calls in AppServiceProvider::boot() accumulate in the same instance throughout the application lifecycle.

Registered Integrations¶

Both WooCommerceIntegration and PrestaShopIntegration declare implements CanExportInBulk, CanVerifyConnections, HasConnectionConfiguration, HasDeletionLog (and use ExportsInBulk, FetchesDeletionLog, VerifiesConnections); WooCommerceIntegration adds CanNotifyDeactivation. WooCommerceIntegration also declares CanPullConsent and HasConsentChannels. PrestaShopIntegration additionally declares implements CanHandleWebhooks, CanPullConsent (use HandlesWebhooks, PullsConsent). UserPlatformIntegration declares implements CanHandleWebhooks, CanPullConsent, CanVerifyConnections, HasConsentChannels (use HandlesWebhooks, PullsConsent, VerifiesConnections): it accepts a Positive User automation's consent webhook and pulls a contact's consent on demand, both only for contacts Conflux created, and writes them into the Positive User connection's own consent mirror (ADR-0044). It implements neither CanExportInBulk nor HasConnectionConfiguration: it is a Push-Out target, not a pull-in source, so it has no bulk export to implement, and it declares no connection-widget configuration fields.

All three are registered in App\Providers\AppServiceProvider::boot(). RapidMail is an internal consuming product with no sync integration built yet, and has no IntegrationRegistry entry.

Exceptions¶

See also¶

• Webhook Receiver — inbound webhook endpoint that dispatches ProcessWebhookJob and routes payloads to handleWebhook()
• Integration Contract design — reasoning behind the design decisions for both directions
• Deletion Log Sync — reasoning behind fetchDeletionLog() and how FetchDeletionLogJob consumes it