QuickBridge is adding two product-facing capabilities that often show up together: a target connector that speaks plain HTTP, and explicit sync run modes so operators control how a run uses stored progress versus a chosen date window.
HTTP Ingest — your API, your payload
Not every destination is QuickBooks or a database. Teams increasingly want sync output to land on a URL they own — a Supabase Edge Function, an internal microservice, a webhook receiver, or a staging API behind API Gateway.
The HTTP Ingest connector is a target: it accepts normalized row documents and delivers them with configurable method, headers, and URL (per connection). Pair it with a bookkeeping or ERP source to push structured payloads without maintaining a bespoke exporter.
QuickBooks Online → HTTP
The qbo-http integration connects QuickBooks Online as the source to HTTP Ingest as the target. Today it focuses on the entities finance teams care about when piping QBO into another system:
| Source (QBO) | Role |
|---|---|
| Customers | Master data for downstream matching |
| Invoices & credit memos | Open and historical billing |
| Payments | Cash application and reconciliation feeds |
Each run produces row-shaped deliveries your endpoint can persist, transform, or fan out. Treat the endpoint as idempotent where possible — retries and bounded windows are first-class in the platform (see run modes below).
Sync run modes — incremental, backfill, replay
Historically, a single manual “sync” button hid important differences: should stored cursors always win over an optional since date? Should a historical window be able to start earlier than the last successful watermark? Should the pipeline skip rows it thinks it already delivered?
We now expose run mode on operator-triggered runs (e.g. from Helm), so intent is explicit:
| Mode | In practice |
|---|---|
| Incremental | The default “keep me current” path. Stored source cursors are respected so a stray date does not rewind production syncs. |
| Backfill | Deliberate historical or gap-filling work. When you set a window, fetch can honor an earlier bound together with your stored cursor using safe precedence — and you can cap the range with an optional until date. Binding deduplication stays on, so idempotent targets are not flooded with duplicates. |
| Replay | Similar window semantics to backfill for fetching, but can bypass document-binding dedup for that run so intentionally unchanged payloads may be delivered again. Use for repair, investigation, or non-production targets — not casually against live accounting. |
Replay can cause duplicate posts if the target is not idempotent or if your business rules disallow duplicates. Prefer backfill for normal history imports; reserve replay for cases where you understand why the ledger skipped delivery and you need a controlled re-emit.
Helm surfaces mode, optional since / until (calendar days in the operator’s timezone, sent as ISO bounds), and a single Run sync action — including from the integrations list for quick access. Audit events record the effective mode and window so support teams can see what was requested.
Why this matters together
HTTP Ingest opens QuickBridge to custom destinations without a new proprietary connector for every stack.
Run modes make ops and support honest: the same “Run” button no longer overloads “catch up,” “import January,” and “force resend” into one ambiguous behavior.
If you are evaluating QBO → your own API, or tightening how your team runs historical imports versus daily incremental syncs, this pair is the foundation.
Learn more
- Connector and integration manifests in-repo:
packages/connectors/http,packages/integrations/qbo-http. - Technical semantics and precedence tables: RFC 022 in the monorepo at
insights/architecture/rfc/022-run-modes-cursor-precedence-and-replay.md(engineering reference). - Operator guide: QuickBridge Dev Docs → Sync lifecycle for a curated summary.