Repull for SaaS platforms — your 20 questions, answered

Yes. This is exactly what the hosted Connect flow is built for: your end-users each authorize their own channel account (e.g. their own Airbnb host account) under your Repull organization. Each connected account is tracked, tokened, and health-monitored independently.

Docs: Connect (multi-channel), OAuth Connect, Connect Widget.

There is no hard technical cap. Limits are plan-based: Free includes 1 PMS connection, Starter includes 5, and the Custom plan is unlimited connections, listings, and API calls. A platform with hundreds or thousands of end-users sits on the Custom plan.

Docs: Pricing.

Yes. Access and refresh tokens are stored per connected account, fully isolated. One user revoking access affects only their account — you receive an account.disconnected webhook for that account with a machine-readable reason; every other account keeps syncing.

Yes. Pass a state parameter when you create the connect session — an opaque pass-through that is returned to you on the redirect alongside the permanent accountId. You map your internal user ID to the accountId once at connection time; connection-lifecycle webhooks then carry that accountId. Connection-level metadata echoed on every webhook delivery is on the near-term roadmap — happy to walk through timing on the call.

Docs: OAuth Connect, Webhooks.

Yes. GET /v1/connect lists every connection in your workspace (id, provider, status, external account id). There is also a dedicated per-channel health endpoint — e.g. GET /v1/channels/airbnb/connection — that returns every connected Airbnb account with its connection status and last-disconnect reason, built to be polled from a status surface.

Docs: API reference, Connect.

Yes — verbatim:

1. 1POST /v1/connect returns a hosted session URL (30-minute TTL)
2. 2Redirect your user to it
3. 3User authorizes Airbnb (or picks another channel from the picker)
4. 4User is redirected back to your redirectUrl with status=connected&accountId=… plus your state
5. 5account.created webhook fires
6. 6Connection is active; the initial sync starts automatically in the background
7. 7Pull data via the API and receive ongoing webhooks

Docs: Connect, Quickstart.

Yes, end to end: Airbnb login, permission/scope handling (read-only vs full access), token exchange, refresh tokens, and expiration handling are all managed by Repull. When a refresh is rejected or access is revoked upstream, the account is flagged and you receive account.disconnected with a reason (refresh_token_rejected, auth_expired, revoked_upstream, manual_disconnect) so you can prompt the user back through the same hosted flow to re-authenticate.

Docs: Airbnb channel.

Yes. There is no separate sandbox — every account gets a single sk_live_*key on signup (free tier, no credit card), so you test directly against the real API: create real properties, reservations, and webhook subscriptions and remove them when you're done. The webhook system has first-class testing tools of its own: POST /v1/webhooks/{id}/test/{event_type} fires realistic fixture payloads for any event type, plus ping and replay endpoints and full delivery logs.

One honest caveat: Airbnb itself does not offer sandbox host accounts, so an end-to-end OAuth test requires a real Airbnb login regardless of environment. Everything downstream of that — webhooks, data shapes, error handling — is fully testable with fixture events, no live Airbnb connection required.

Docs: Manage webhooks.

Yes. The hosted Connect pages are white-labeled per organization: app name, logo (light and dark variants), primary and accent colors for both themes, support email in the footer, your own terms and privacy URLs, and a default redirect URL.

Docs: Connect Widget.

Yes. Connections are one-per-channel and a user can hold several simultaneously — Airbnb + Booking.com + Vrbo + a PMS. The hosted session can show a multi-channel picker or be locked to specific providers via allowed_providers.

Docs: Connect (multi-channel), PMS coverage.

Yes. DELETE /v1/connect/{provider} revokes the OAuth token where the channel supports it, purges stored credentials, and stops all sync jobs for that connection.

Yes. GET /v1/listings is cursor-paginated and filterable by ?channel=airbnb|booking|vrbo. Every listing carries a channels[] array with the platform, the original channel property ID (externalId), and active/sync status — so you always know which channel each property belongs to and its native ID. Optional ?include=content,details,amenities expansions.

Docs: List Properties, Property Details, Listing Content & Details.

Airbnb: yes — POST /v1/channels/airbnb/reviews/{id}/respond writes the public host response straight through to Airbnb. Booking.com: yes — host replies are supported the same way. Vrbo: not yet — Vrbo reviews are readable via the unified API, but Vrbo does not expose a response-write path we are comfortable shipping yet.

Docs: Reviews.

Yes. GET /v1/reviews is a unified cross-channel review stream (Airbnb, Booking.com, Vrbo) with filters for platform, listing, rating range, responded/unanswered status, and guest-vs-host reviews. Review updates — including host responses — are reflected on the same records.

Dedicated review.created / review.updatedwebhook events are on the near-term roadmap; today most integrations poll the reviews endpoint, which is cheap — cursor-paginated and served from our database, never from a live channel call. Let's discuss your latency requirements on the call.

Docs: List Reviews.

The live catalog is at Webhook event types and machine-readable at GET /v1/webhooks/event-types (with sample payloads). Current events:

Deliveries are HMAC-SHA256 signed (Stripe-style) with retries, replay, and full delivery logs: Verify signatures, Retries, Manage webhooks.

Syncs are background jobs. Connecting an account fans out parallel sync pipelines — listings, calendar/pricing, messages, reviews, transactions — on our queue infrastructure; you do not manage any of it. Initial sync duration is dominated by the channel's own rate limits, so it scales with account size: large portfolios complete in the background while the connection is already usable.

Reads are paginated at up to 100 items per page with cursor pagination (stable at any depth), so 100,000 reviews is roughly 1,000 calls — trivial against the default rate limit of 600 requests per minute. Ongoing changes arrive via webhooks, so you never re-crawl.

Docs: Rate limits, Idempotency.

Synchronized.Repull syncs channel data into our own database and serves the API from there. That is a core design decision: fast, consistent reads that never block on — or get rate-limited by — Airbnb's API, and your app keeps working even while an upstream is flaky. Responses include a data_freshness envelope (last_synced_at, stale flag) so you always know how fresh the data is.

Listings + API call volume per plan — not per reservation, review, or webhook. Free: $0, 3 listings, 1,000 calls/month. Starter: $99/month, 10 listings, 100,000 calls/month, 5 connections, webhooks included. Custom: unlimited listings, calls, and connections, with a custom SLA and dedicated support.

Docs: Pricing, Credits & usage.

That is Custom-plan territory and exactly what our call is for. Pricing at that scale depends on listing counts per user and API volume, and we price it as a platform partnership rather than a per-seat rack rate. We'll bring a concrete proposal structure to the call.

Starter includes email support; Custom includes dedicated support with a custom SLA — for a platform integration of your size we would set up a shared Slack channel with our engineering team.

Day to day, the API is built to be self-serve: every error response carries a request_id, a machine-readable code, a fix field with the exact next step, and a deep link into the error docs.