Expected load questionnaire¶
Help OpenAP size the receiver for your traffic. OpenAP runs the eCAPI endpoint on elastic infrastructure, but capacity, rate limits, and monitoring are tuned per advertiser and reviewed against the numbers you give here. Sharing realistic estimates up front — and flagging spikes before they happen — keeps your events flowing at 200 instead of hitting 429/throttling during your most important moments.
Complete this during onboarding (see Getting provisioned), and send an update whenever your expected volume changes materially or a large spike is coming. Estimates are fine — we'd rather size for a rough number than be surprised by an exact one.
How to think about the numbers¶
- Event = one Event Object. Request = one HTTP
POST, which may carry a batch of up to 1,000 events. Both matter: rate limits apply per request and per event (see API reference — Rate limits). - Give numbers per
data_set_idif you send to more than one, plus a combined total. - Use your own peak windows (per second is ideal; if you only know daily volume, say so and we'll convert).
1. Contact and scope¶
| Field | Your answer |
|---|---|
| Company / integration name | |
| Technical contact (name, email) | |
| Escalation / on-call contact for launch windows | |
data_set_id(s) in scope |
|
| Target go-live date | |
| Environment(s) — test, production |
2. Steady-state volume¶
Your normal, day-to-day load once integrated.
| Metric | Your answer |
|---|---|
| Average events/second (typical) | |
| Average requests/second (typical) | |
| Total events/day | |
| Typical batch size (events per request) | |
| Daily pattern (e.g. business-hours peak, overnight quiet, timezone) | |
| Do you send in real time, micro-batches, or periodic bulk uploads? |
3. Peak / maximum volume¶
The busiest you realistically expect to get in normal operation (not counting the planned spikes in §4).
| Metric | Your answer |
|---|---|
| Peak events/second (sustained, e.g. 5-min) | |
| Peak requests/second (sustained) | |
| Absolute max events/second (brief burst) | |
| Largest batch size you'll send | |
| When peaks typically occur (time of day, day of week, seasonality) |
4. Planned spikes and campaigns¶
Known events that will drive load well above your steady state — sales, product launches, campaign kickoffs, seasonal peaks (Black Friday, ticket on-sales, sporting events, etc.).
For each anticipated spike:
| Field | Your answer |
|---|---|
| What / why (e.g. "Black Friday", "Super Bowl campaign") | |
| Date(s) and time window (with timezone) | |
| Expected peak events/second during the spike | |
| Expected multiple of steady state (e.g. 10×, 50×) | |
| Ramp shape — instant surge, or gradual over minutes/hours? | |
| How much advance notice can you give OpenAP? |
Please notify OpenAP of large spikes at least 5 business days in advance (more for anything ≥10× steady state or above your reviewed rate limits). Email your OpenAP representative with the date, expected peak, and duration so capacity and rate limits can be pre-scaled. Unannounced spikes above your provisioned limits may be throttled (
429).
5. Traffic characteristics¶
Details that affect how we scale and shard.
| Field | Your answer |
|---|---|
Event types you send (e.g. purchase, page_view, add_to_cart) |
|
| Typical payload size per event (rough KB, or fields per event) | |
| Are events spread evenly, or bursty (e.g. hourly cron dumps)? | |
Retry behavior on 429/5xx (do you back off? honor Retry-After?) |
|
| Failover/replay: can you buffer and re-send if we ask you to pause? | |
| Any hard ordering or latency requirements? |
6. Rate limits¶
Current defaults per data_set_id (see API reference — Rate limits):
| Limit | Default |
|---|---|
| Sustained requests/second | 1,000 |
| Burst requests/second (over 60s) | 5,000 |
| Sustained events/second (across batches) | 100,000 |
| Field | Your answer |
|---|---|
| Do the defaults cover your steady-state and peak numbers above? | |
If not, what sustained/burst limits do you need, and for which data_set_id? |
Return this to your OpenAP representative. OpenAP will confirm your provisioned rate limits and any capacity adjustments before go-live, and will work with you on notification timing for recurring spikes.