Below is the revised Help Center version with your clarifications incorporated and an added FAQ section.

Setting Up Brij API Jobs in Your ETL Provider

To properly ingest Brij data into your warehouse, configure the following automated jobs in your ETL platform (Portable, Fivetran, etc.).

Four jobs are typically required:

• 2 recurring daily jobs (analytics + customers)
• 2 optional one-time backfills (analytics + customers)

1. Daily General Analytics Sync

Purpose: Retrieve daily analytics metrics with daily granularity.

Endpoint: General Analytics
Schedule: Daily
Parameters:

• start = [yesterday - using 00:00:00 timestamp]
• end = [yesterday - using 23:59:59 timestamp]

Important Behavior:

• The analytics endpoint requires a date range.
• The date range can be any length (e.g., one year).
• The response returns one row per Brij Experience, with metrics aggregated across the requested date range.

Why daily imports are recommended:

If you request large date ranges, metrics will be totaled across that entire range.
Running this job daily allows you to:

• Store one row per Experience per day
• Build granular trend charts (e.g., daily scans, daily registrations)

Load Behavior: Append by date (recommended).

2. Daily Customer Sync

Purpose: Retrieve new customer registrations and/or rebates.

Endpoint: Registrations and/or Rebates
Schedule: Daily

All endpoints support page-number–based pagination. Ensure your ETL job increments through all pages until no additional records are returned.

Recommended Configuration (Completed Registrations Only)

Parameter:

• approvalDate start = [yesterday - using 00:00:00 timestamp]
• approvalDate end = [yesterday - using 23:59:59 timestamp]

Why use approvalDate?

• Ensures the registration or rebate was fully completed.
• Excludes incomplete registrations.

Alternative Option A: Created Date or Approval Date

Parameter:

• createdDate start = [yesterday - using 00:00:00 timestamp]
• createdDate end = [yesterday - using 23:59:59 timestamp]

Use case:

• Capture email/phone submitted at step one of registration.
• May include incomplete registrations.
• May exclude completed form/survey/purchase data if the user abandoned the flow.

Alternative Option B: Full Sync (No Date Filter)

Configuration:

• Remove date filters.
• Retrieve full paginated dataset.
• Overwrite or upsert all customer records each run.

Use case:

• Full-state reconciliation.
• Requires proper pagination handling.

3. Historic One-Time Customer Import (Optional)

Required only if your brand was live before enabling API sync.

Endpoint: Registrations and/or Rebates
Parameters: None (no date filters)

Configuration:

• Run full paginated import.
• Overwrite or upsert all records.
• Execute once the day before enabling the daily sync.

4. Historic One-Time Analytics Import (Optional)

Required only if your brand was live before enabling API sync.

Endpoint: General Analytics

Configuration:

• Create a loop in your ETL job.
• Request analytics one day at a time from launch date through yesterday.
• Append results by date.

After this completes, the Daily General Analytics Sync will keep data current.

Technical Notes

Pagination

All endpoints use page-number–based pagination.
Your ETL job should:

• Increment page numbers sequentially
• Stop when an empty response (or fewer than page size results) is returned

Recommended Request Limits

Although Brij does not currently enforce rate limits, we recommend the following best-practice guardrails:

• Maximum 5 requests per second
• Maximum 10,000 records per job run before implementing batching safeguards
• Exponential backoff on failed requests

These limits help ensure long-term stability and align with common SaaS API best practices. Official rate limits may be introduced in the future.

FAQ

Why not request a full year of Analytics each day?

You can request any range as you may be using the API for other uses cases. However, if you are using this to feed into your BI Tool's database, we recommend requesting daily data. The analytics endpoint aggregates metrics across the requested date range and returns one row per Experience. Pulling large ranges prevents you from storing daily-level trend data. Daily date windows preserve reporting flexibility.

Should we use approvedFrom/To or dateFrom/To filters?

There are three supported approaches:

Option 1: Approval Date (Completed Registrations)

Use:

• approvedFrom = [yesterday - using 00:00:00 timestamp]
• approvedTo = [yesterday - using 23:59:59 timestamp]

Best for:

• Reporting on fully completed registrations or approved rebates
• Ensuring survey responses and/or purchase details are included in registration data

WebApp Note:
For most WebApp registrations, brands do not require manual approval. In these cases:

• approvalDate is automatically set when the consumer completes their submission.
• If the registration contains additional questions or purchase fields, approval occurs upon full submission.
• If no additional questions exist, the registration may be created and submitted simultaneously, and approval may occur at that same time.

Rebate Note:
For rebate experiences, there will always be a difference between createdDate and approvalDate, as rebates require review and approval.

Option 2: Created Date (Initiated Registrations)

Use:

• createdDate start = [yesterday - using 00:00:00 timestamp]
• createdDate end = [yesterday - using 23:59:59 timestamp]

Best for:

• Capturing email/phone collected at the first step
• Tracking drop-off or partial registrations

May include:

• Incomplete flows
• Records without full survey or purchase data

Option 3: Capture Both (Recommended for Advanced Reporting)

Configure two daily jobs:

1. Initiated Registrations Table
   • Filter by createdDate
   • Store in a table such as initiated_registrations
2. Completed Registrations Table
   • Filter by approvalDate
   • Store in a table such as completed_registrations

This allows brands to:

• Measure conversion from initiation → completion
• Analyze registration funnel performance
• Preserve full reporting flexibility

Do we need the historic imports?

Only if your brand was live before enabling API sync.
If launching API sync at the same time as your program launch, daily jobs are sufficient.

Before Building Custom Jobs

Many ETL providers (e.g., Portable, Fivetran) may already have prebuilt Brij connectors or templates.

Before building custom jobs, check whether your ETL provider offers an official Brij template. If available, use the provider’s native Brij template instead of configuring custom API jobs.