Connector assurance

Not every connector is equally deep. Here’s exactly how deep each one is.

This registry is generated from the engine. For every connector and action it shows the checks that run, what the verification correlates on, whether reversals are monitored, and the verified limits of the integration. A connector that returns a state the engine does not recognize degrades automatically and stops issuing finalized verifications until it is patched. The deepest path today is Stripe refunds.

Every connector is pinned by contract tests against recorded real-shape provider responses, and every credential is exercised with a live read-only check the moment it is connected. Safe marks whether a verified action reaches safe_to_claim_complete, which requires every check the contract marks required to actually run. A connector that returns a provider state the engine does not recognize flips to degraded and stops issuing finalized verifications until it is patched.

Refunds

Each verification reads the refund from the system of record, checks amount, currency and settlement state, and lists the charge's sibling refunds to rule out a double refund of one operation.

Connector	Status	Safe	Duplicate check	Specifics
stripe	beta	reachable	operation_ref same-charge + Postcept cross-charge index	Reversal is caught via re-verification and webhooks, not a dispute-stream subscription. Continuous live canary is in progress.
square	experimental	reachable	reason same-charge listing + Postcept cross-charge index	Verified against recorded provider fixtures. Live canary coverage is in progress. Duplicates are listed from the payment's refund list, correlated on reason, which the agent sets to its operation id when creating the refund. The provider does not expose a customer on the refund object, so the customer match is skipped. It is optional corroboration.
paypal	experimental	reachable	custom_id same-charge listing + Postcept cross-charge index	Verified against recorded provider fixtures. Live canary coverage is in progress. Duplicates are listed from the order's refund list, correlated on custom_id, which the agent sets to its operation id when creating the refund. The provider does not expose a customer on the refund object, so the customer match is skipped. It is optional corroboration.
braintree	experimental	reachable	orderId same-charge listing + Postcept cross-charge index	Verified against recorded provider fixtures. Live canary coverage is in progress. Duplicates are listed from a refunded-transaction search, correlated on orderId, which the agent sets to its operation id when creating the refund. The provider does not expose a customer on the refund object, so the customer match is skipped. It is optional corroboration.
quickbooks	experimental	reachable	DocNumber same-charge listing + Postcept cross-charge index	Verified against recorded provider fixtures. Live canary coverage is in progress. Duplicates are listed from a DocNumber query, correlated on DocNumber, which the agent sets to its operation id when creating the refund. The provider does not expose a customer on the refund object, so the customer match is skipped. It is optional corroboration.
netsuite	experimental	held	Postcept cross-charge index only	Verified against recorded provider fixtures. Live canary coverage is in progress. Provider-side refund listing is in progress, so the duplicate check runs on Postcept's cross-charge index only and safe stays out of reach. NetSuite may return a currency name rather than an ISO code, so the required currency check can skip, which also holds back safe.
shopify	experimental	reachable	note same-charge listing + Postcept cross-charge index	Verified against recorded provider fixtures. Live canary coverage is in progress. Duplicates are listed from the order's refund list, correlated on note, which the agent sets to its operation id when creating the refund. The provider does not expose a customer on the refund object, so the customer match is skipped. It is optional corroboration.
adyen	experimental	held	Postcept cross-charge index only (no provider refund listing)	Webhook-backed (asynchronous confirmation), not a synchronous read. Verified against recorded fixtures and a pinned HMAC. Live canary coverage is in progress. Duplicate detection uses Postcept's cross-charge operation index. Provider-side refund listing is in progress, so a confirmed refund verifies without reaching safe-to-claim. The webhook does not carry a customer, so the customer match is skipped.
relay	beta	reachable	relay-reported (relay observes the provider)	Facts are only as good as the customer relay's read. The receipt names the relay.

Support tickets

Each verification reads the ticket and confirms it reached a final state. A ticket the customer later reopens is caught on scheduled re-verification and the verification flips to reversed.

Connector	Status	Safe	Duplicate check	Specifics
zendesk,gorgias,intercom,hubspot,front,servicenow,salesforce	beta	reachable	status re-verified over time	None

Applies to every row above: A reopen is caught on scheduled re-verification, not a provider webhook stream. Merge tracking is in progress.

Cancellations

Each verification reads the subscription and confirms it actually ended.

Connector	Status	Safe	Duplicate check	Specifics
stripe	experimental	reachable	status re-verified over time	None

Applies to every row above: Subscription lifecycle is shallower than the refund path.