Documentation · Reference
Limits & Quotas
Plan limits, API rate limits, sync failure behaviour, mid-cycle plan changes, trial scope, and data retention for airsource.
1. Plan limits
Per-plan ceilings on sources, monthly throughput, sync cadence, and API rate limit. Numbers mirror /pricing exactly.
| Plan | Price | Sources | Records / rows | Sync cadence | API rate limit | Support |
|---|---|---|---|---|---|---|
| Starter | $9/mo | 1 source × 1 destination | 100 records/month | 15-minute scheduled sync | 60 requests/min | Community support |
| Pro | $29/mo | 5 sources × 3 destinations | 10K rows synced/month | Realtime (webhook) where available + 15-minute fallback | 120 requests/min | Email support |
| Business | $99/mo | Unlimited sources & destinations | 100K rows synced/month | Realtime (webhook) where available + 15-minute fallback | 600 requests/min | Priority support |
2. API rate limits
Ceilings for /api/* endpoints. Bursts past the limit return HTTP 429 with a Retry-After header (seconds).
| Scope | Limit | Notes |
|---|---|---|
| /api/* (default, unauthenticated) | 60 requests/min per IP | Applies to /api/waitlist and other public endpoints. Bursts above the limit are rejected with HTTP 429. |
| /api/* (Starter / Pro session) | 60-120 requests/min per session | Matches the plan limit column above. |
| /api/* (Business session) | 600 requests/min per session | Suitable for dashboard polling, bulk schema inference, and webhook reprocessing. |
| /api/cron/* (internal) | Unlimited (Bearer-authenticated) | Invoked by GitHub Actions every 15 minutes. Customer traffic cannot reach these routes. |
429 response shape
HTTP/1.1 429 Too Many Requests
Retry-After: 30
Content-Type: application/json
{
"ok": false,
"error": "rate_limit_exceeded",
"retry_after_seconds": 30
}Clients should honour the Retry-After header and back off accordingly. The official airsource SDK and the internal withRetry helper handle this automatically.
3. Sync failure behaviour
Every sync goes through the withRetry helper. Failures are persisted, dashboard-visible, and reprocessable.
| Field | Value | Source |
|---|---|---|
| Maximum attempts | 3 | src/lib/retry.ts withRetry maxAttempts default |
| Base delay | 500 ms | src/lib/retry.ts baseDelayMs default |
| Backoff strategy | Exponential with full jitter (random(0, base * 2^attempt)) | src/lib/retry.ts computeDelay |
| Maximum delay cap | 8000 ms (8 s) | src/lib/retry.ts maxDelayMs default |
| Retryable errors | HTTP 429 (Stripe / Airtable rate limit), HTTP 5xx, ECONNRESET / ETIMEDOUT / ECONNREFUSED, fetch failures | src/lib/retry.ts defaultIsRetryable |
| Failure persistence | Recorded to airsource.sync_errors with attempt_count, error_message, occurred_at, resolved_at | src/lib/sync-errors.ts |
When a sync raises a retryable error (rate limit, network blip, transient 5xx), the helper waits with exponentially-jittered backoff and tries again — up to 3 attempts in total. After the third failure the error is appended to airsource.sync_errors with the full message, attempt count, and timestamp.
You can audit every failed sync from the dashboard. Each entry surfaces an idempotent re-run button (POST /api/integrations/[id]/retry) and a resolve toggle once you have fixed the upstream cause.
4. Mid-cycle plan changes
How upgrades, downgrades, cancellations, and refunds work when you change plans inside a billing period.
| Scenario | Behaviour |
|---|---|
| Upgrade mid-cycle (e.g. Starter → Pro, Pro → Business) | Effective immediately. Stripe automatically prorates the higher-tier amount for the remaining days of the current billing period. |
| Downgrade mid-cycle | Takes effect at the end of the current billing period. You keep the higher-tier features until then; no credit is issued for the unused upgrade window. |
| Cancellation | Subscription remains active until the end of the current billing period, after which the account drops to read-only. |
| Refund policy | Not yet defined — contact support@airsource.io. A written refund policy will land before the Stripe live-mode switch (tracked separately as Layer C / L12 in production-readiness). |
5. Onboarding period
The 14-day private beta access is the onboarding for invited users: full Pro feature set, private beta collected up-front.
| Field | Value |
|---|---|
| Length | 14 days from sign-up |
| Credit card required | No (Stripe payment_method_collection: if_required) |
| Feature scope | Pro-equivalent: full access to AI schema mapping, every live connector, 15-minute scheduled sync, retry + sync_errors dashboard. |
| Auto-charge | No surprise charges. If no payment method is added before day 14, the trial simply ends and the account is paused (no charge) until you choose a plan. |
| Reminder | Email sent 3 days before trial end (trial-reminder cron, /api/cron/trial-reminder). |
6. Data retention
How long airsource keeps each class of data, and how to request deletion or export under GDPR.
| Data class | Retention | Notes |
|---|---|---|
| Account metadata (email, integrations config, mapping rules) | Kept while the account is active. | Deleted within 30 days of account closure (see GDPR DSR below). |
| Synced business records (Stripe charges, Shopify orders, etc.) | Not stored long-term in airsource. | Records flow source → AI mapping → destination. airsource is a passthrough; the canonical copy lives in your Airtable / Google Sheets / Notion destination. |
| Raw webhook events (airsource.events_raw) | 30 days, then pruned. | Kept short-term for debugging and re-sync. Source: OVERVIEW.md §4 (Phase γ). |
| Sync failure history (airsource.sync_errors) | 90 days rolling. | Surfaced in dashboard so you can audit retry attempts. |
| Deleted accounts | 30-day grace, then full purge. | Within the grace window we can restore on request. After 30 days the deletion is irreversible. |
GDPR / CCPA data subject requests
To request export or deletion of your personal data, email privacy@airsource.io. We acknowledge inside 72 hours and complete the request inside 30 days, per the Privacy Policy.