Marketplace sync designed to be boring, not adventurous.
Connector reliability is the invisible variable that decides whether your team trusts the dashboard. Zobrx ingest engineers the failure modes — silent credential expiry, partial-day ingestion, report-poller loops, cross-tenant scope leaks — as explicit invariants: connect-time historical backfill on every tenant, sticky-error 3-strike circuit-break for dead SP-API stores, SQS-backed on-demand drain, operator-driven ranged re-sync, and a /needs-reconnect endpoint that surfaces dead connectors before downstream metrics regress.
Six reliability invariants, by design
Each one comes from a specific incident the team debugged in production. We rebuilt the connector layer around them so the failure modes do not recur.
Connect-time historical backfill
Every new tenant connector triggers a one-time historical backfill the moment credentials are saved. No 'wait 14 days for data to populate' — your dashboard is useful on day one. Backfill is subscription-triggered, idempotent, and once-only.
Sticky-error 3-strike circuit-break
Dead SP-API stores (and equivalents on Flipkart, Snapdeal, Myntra) are detected after 3 consecutive failures and break-circuit out of the scheduler. Surface to the operator console; no more silent burn-through of API quota retrying a dead credential.
/needs-reconnect endpoint
A single endpoint groups all sticky-failed connectors per tenant by channel × store. Operators (or customer admins via the in-app health surface) see exactly what needs human action — and ranged on-demand re-sync triggers re-attempt the moment credentials are fixed.
SQS-backed on-demand drain
On-demand sync requests route through an SQS queue with DLQ + per-tenant rate limits. Audit-sink consumer logs every drain. Operators can replay a window manually without affecting the scheduled cron — useful during incident recovery or customer-requested re-sync.
Operator-driven ranged re-sync
Admin / support tooling can trigger a ranged re-sync per (tenant × channel × store × date-window) without rebuilding the entire historical. Useful when a customer notices a settlement-period gap and asks for surgical reconciliation.
First + last record dates from real data
The sync-health dashboard reports first + last actually-ingested record dates per (tenant × channel × store), not 'last sync attempted' timestamps. Customers can see exactly what window is covered without having to read scheduler logs.
Four real failure modes, four hardenings
These are the incidents that shaped the current connector architecture. Naming them publicly is part of the trust contract.
Silent credential expiry
Amazon SP-API refresh-token expires every 6 months; a connector silently stops returning new data but does not error in an obvious way.
Sticky-error 3-strike circuit-break surfaces the dead connector after 3 consecutive failed attempts. Tenant + operator both see it in /needs-reconnect within hours, not weeks.
Partial-day ingestion looks like a real OOS
A scheduler restart at 14:30 IST means yesterday's afternoon settlements never landed. Dashboard reports a stockout spike that did not happen.
Stale 'running' rows orphaned by mid-tick restarts are reaped on next-tick start. Scheduler honours cron on next attempt rather than on next discovery — so the window is re-covered cleanly.
Report-poller forever loop
Marketplace re-issues an old settlement report; the poller treats it as new and re-parses, producing duplicate ledger rows.
Idempotent run-keys on (reportType, runDate) plus dedup at the order-item layer. Re-parse of a known-completed scraper run is gated.
Cross-tenant data leakage during error paths
An error-path code branch in a worker fails to apply tenant scope; cross-tenant data ends up in the wrong audit sink.
Tenant-context discipline is a first-class invariant — workers wrap in runWithTenantContext, error-path writes are scope-checked, and CROSS_TENANT_FILTER is required on terminal-fail ledger writes. Tested.
Where reliability concerns diverge from Funnel / Improvado / Supermetrics
Those tools are strong ad-platform connector suites. Zobrx adds Indian marketplace + Q-Com depth and an explicit reliability layer, because connectors that quietly die corrupt Brand Score and Leak Ledger downstream.
| Capability | Zobrx | Funnel | Improvado | Supermetrics |
|---|---|---|---|---|
| Connect-time historical backfill (Day 1 useful data) | ✓ | Manual setup | Manual setup | User-triggered, limited window |
| Sticky-error circuit-break (auto-detect dead connector) | ✓ | — | — | — |
| /needs-reconnect dashboard endpoint | ✓ | — | Partial | — |
| Operator-driven ranged re-sync (no full rebuild) | ✓ | Support ticket | Support ticket | Support ticket |
| Indian marketplaces (Flipkart, Snapdeal, Myntra, Meesho, ONDC) | ✓ | Limited | Amazon-only India | Amazon-only India |
| Quick Commerce platforms (Blinkit / Zepto / Instamart / BB Now) | Via Q-Radar | — | — | — |
| Tally + GSTR-2B reconciliation | ✓ | — | — | — |
| Audit-sink hash chain on ingest provenance | ✓ | — | — | — |
Comparison built from Funnel.io, Improvado and Supermetrics public product pages, G2 reviews and customer demo recordings as of Q2 2026. We respect each of these tools; the framing is what differs between an ad-connector suite and an India-first marketplace platform.
Common questions for the data / IT lead
Where this fits in the platform
80+ connectors across ads, analytics, marketplace, accounting and AI.
Coach treats sync staleness as a first-class anomaly.
The Tally + GST workflow relies on reliable marketplace ingest.
Q-Radar PSL hashes onto the same audit sink as connector provenance.
SOC 2 / DPDP-aligned audit sink underpinning every ingest row.
We will walk you through the connector internals on request.
Reliable connectors are the foundation of everything else.
Brand Score is only as good as its inputs. Q-Radar PSL is only as good as the scrape window covered. Tally export is only as good as the settlements reconciled. Reliability is not a feature — it's the foundation. Talk to us.
- ✓ 14-day free trial
- ✓ No credit card
- ✓ Cancel anytime