Skip to main content
Effective date: 2026-08-20 This document is intended for technical teams evaluating or building on top of the Edpire API.

Infrastructure Overview

Compute auto-scaling: Vercel serverless functions scale automatically with traffic. There is no warm-up period on primary API routes. Cold starts do not apply to Edge-deployed routes. Database scaling: PgBouncer pools connections to the PostgreSQL instance, preventing connection exhaustion under concurrent load. The database is the primary scaling constraint — see rate limits below for the limits that protect it.

API Rate Limits

Rate limits are applied per organization, on a rolling 60-second window, and every API key your organization holds shares that allowance. When a limit is exceeded, the API returns 429 Too Many Requests with a Retry-After header indicating how many seconds to wait. The figures below are the minimum every paid plan receives. Larger bands resolve to proportionally higher limits, because a cohort that all begins an exam within the same two minutes generates far more than the floor: a 500-learner band, for example, receives 250 submits per minute rather than 100. Your organization’s actual limits are shown on your plan page in the dashboard, and stated in your quote. Purpose: rate limits are a technical safeguard for the platform, never a commercial dial. They are sized so that normal traffic, including your busiest exam window, never reaches them. Shared limits: rate limits apply to the organization, not to individual learners. If your integration routes all learners through one backend (the standard setup), design it to aggregate and respect these limits.

How Active Learners Are Counted

This is the only number that affects your price, so it is defined precisely here.

In one sentence

A learner counts once per licence year, the first time they submit an assessment. Not when they register on your platform. Not when they log in. Not per attempt. A learner who submits sixty assessments across the year is one learner.

What we actually count

Every submission carries an identity. We count the distinct identities that submitted at least once during your licence year: The two live in separate namespaces, so an Edpire account and a learner_ref can never collide.

What is NOT counted

  • Registered users who never submit. If you have 3,000 accounts and 400 of them use assessments this year, you are billed for 400.
  • Anonymous takers on open public links. A link that spreads further than you expected cannot change your band or your bill.
  • Attempts, retries and resumes. Same learner, same identity, counted once.
  • Started but unsubmitted work. Only a completed submission establishes a learner.

The one thing you control, and should get right

Send a stable learner_ref for each of your users, and never change it. If your backend sends user-4821 every time for the same student, that student is one learner for the whole year. If it sends a fresh random value each session, the same student counts as a new learner each time and your own bill goes up for no reason. A stable identifier is one line in your integration and it is the single most important thing to get right. Anonymised or hashed identifiers are fine, and encouraged: we never need to know who the person is, only that it is the same person. sha256(your_user_id) works perfectly, as long as it is deterministic.

Verifying it yourself

Your dashboard shows the live count for the current period, and the definition next to it. You do not have to take our word for the number, and you will never see it for the first time on an invoice: we email at 80% and 100% of your band.

Monthly Usage Quotas

These are anti-abuse ceilings, not a meter. Passing one is never billed, never throttled, and never interrupts your service. They are sized from your band so that normal pedagogical use cannot reach them: at 60 submissions per learner per month, a cohort would have to submit an assessment every working day to approach the ceiling. The only thing that happens when you pass one is an email, so that your growth is visible to you early. The one number that does change your price is your population band, and crossing that is handled in Commercial Terms, not here. Usage quotas reset on the 1st of each calendar month at 00:00 UTC.

Submission Quota

A submission is counted each time a learner completes and submits a full assessment, through any delivery path: the REST API (POST /assessments/{id}/submit), the embedded SDK player, or an Edpire-hosted share link. Partial saves, draft states, and preview calls are not counted. Included volume scales with your band at 60 submissions per learner per month.

API Call Quota

An API call is counted for each request to the /check endpoint or any read endpoint (GET requests). Write endpoints other than /submit (e.g., webhook registration) are not counted against this quota. Included volume scales with your band at 1,000 API calls per learner per month.

Passing an Included Quota

Nothing is billed and nothing is blocked. Included quotas are abuse protection, not a meter. Calls past a ceiling continue to succeed, and no charge of any kind results. Edpire sends an email notification at 80% and 100% of each monthly quota so that growth is visible to you early. If your usage sits above a ceiling consistently, it generally means a larger band suits you better, and we will raise it with you. See Commercial Terms.

Testing and Development

Is there a sandbox?

There is no separate sandbox environment, deliberately. You test against the real API with a test organisation, which means the behaviour you validate is exactly the behaviour you ship. Sandbox environments drift from production, and an integration that passes in a sandbox and fails in production is the worst outcome for both of us.

Before you sign

Create a free workspace. It carries the full REST API, the SDK, webhooks and every question type, with a monthly ceiling of 100 submissions. That is sized for building and validating an integration end to end, and it is deliberately too small for production, which is the only thing that separates it from a paid plan. You can therefore build and prove the entire flow, including grading and webhook delivery, before any commitment.

After you sign

Your organisation is provisioned on your band immediately, so integration testing runs against your real included volume (30,000 submissions a month at the ≤500 band). In practice the ceiling stops being something you think about.

Test data in production

Use your organisation on production for QA. No approval needed. Test submissions are real records, and they can be identified and excluded from your analytics on request, so they never pollute your reporting.

Load testing and attack simulation

These need an isolated environment, because they would otherwise affect other customers. See Security Testing Policy below: a separate deployment with its own database is provisioned for a defined window, typically two weeks, on five business days’ notice.

API Response Times

The following commitments apply to production API endpoints under normal load: Excluded from response time guarantees:
  • Endpoints that trigger AI evaluation (grading latency depends on third-party model response times)
  • File upload endpoints (latency scales with file size)
  • Endpoints called during database maintenance windows

Data Retention


Security Testing Policy

Edpire supports responsible security testing by integration partners under the following conditions:

Standard QA Testing

Use your test organization on the production environment. Test submissions are real records but can be identified and excluded from analytics on request. No approval needed.

Penetration Testing / Attack Simulation

Edpire offers a planned pen test window for clients who require the ability to run load tests, attack simulations, or chaos engineering:
  • A temporary isolated environment (separate Vercel deployment + isolated database) is provisioned for a defined testing period (typically 2 weeks)
  • Testing is scoped to that isolated environment — production and other clients’ data are never in scope
  • A written request must be submitted to support@edpire.com at least 5 business days in advance
  • Testing dates, scope, and source IPs must be agreed upon before the window opens
Unauthorized testing against the production environment or other clients’ data is prohibited and may result in immediate account suspension.

Status & Uptime

Live platform status and incident history: status.edpire.com (coming soon) Subscribe to status updates via email at support@edpire.com.
Edpire — support@edpire.com