Frequently asked questions

Retrybase turns broken customer integrations into a controlled recovery workflow: classify the failure, suppress incident noise, notify the right person, guide reconnection, and verify the connection is actually healthy.

No. It sits beside your existing OAuth implementation, integration code, iPaaS, unified API, or provider SDK.

SaaS teams that own customer-facing integrations and need a reliable way to detect, explain, and recover broken connections.

Not yet. The product is in early access, and the public website remains intentionally excluded from search indexes during launch testing.

The durable event, classification, recovery, notification, verification, and reporting backend is running. A real Salesforce reference recovery has completed end to end.

No. Your application continues to own OAuth, provider credentials, token refresh, and provider API calls.

Send a normalized failure event containing your connection identifier, provider, timestamp, error code or HTTP status, and optional business metadata.

Your application runs a lightweight provider health probe and posts a verification result for the specific recovery attempt. Verification is authoritative; a browser return alone is not proof.

Yes. Optional heartbeats let the watchdog identify connections that stopped reporting even when your application emitted no explicit error.

The event model is provider-independent. The Salesforce reference flow is operational. HubSpot and Google recovery hosts are planned but are not yet generally available.

Retrybase correlates failures before notifying. Connections may be suppressed behind a provider incident so customers are not asked to fix something outside their control.

No. Provider tokens remain inside your application or dedicated recovery host. Retrybase receives normalized operational events and verification results, not provider credentials.

No. Retrybase is outside the data plane and does not need access to the records moving through an integration.

No. Provider authorization and health checks are performed by the host application. Retrybase does not write to Salesforce, HubSpot, Google, or other providers.

It stores connection identifiers chosen by the SaaS application, normalized codes and statuses, timestamps, classifications, recovery state, notification outcomes, and optional business-impact metadata. Secret-looking fields are redacted before write.

Recovery links are signed, time-limited, and rate-limited. Opening the page does not start recovery, and the same link can be reopened to retry until it expires. Provider return state is separately signed, short-lived, bound to one attempt, and single-use.

No. Event receipts, workflow handlers, notifications, and scheduled actions use durable idempotency keys. Work is delivered at least once but applied once logically.

Each attempt has a tenant-configurable verification deadline with a safety floor. The attempt expires back to action required instead of remaining in recovery forever.

A late healthy result is accepted as truth and recorded as a late verification rather than discarded.

The first transport records submission, delivery, bounce, complaint, and open callbacks. Opens are treated as weak delivery evidence, never as proof of recovery.

Yes. Coverage reporting identifies stale or missing heartbeats and compares watchdog-detected failures with failures reported by your own instrumentation.

Yes. Use a test project, a test inbox, and provider developer accounts. The Salesforce reference host uses a Developer Edition organization and a record-free limits probe.