Webhooks

Last updated 2026-06-08

Planned feature. This describes upcoming functionality. The product behavior may change before release.

View raw markdown

At a glance

  • Who uses it: Districts with downstream data warehouses, MTSS dashboards, or notification platforms.
  • When to use it: When you need real-time push of case events into your own system.
  • Permissions required: Administrator at the district level.
  • Status: Planned — case event payloads are stable internally; the outbound webhook surface is being scoped per customer.

Purpose

Webhooks deliver AmplifyED events (case created, case status changed, follow-up due, case closed) to a URL of your choosing so your downstream systems can react in real time.

What's available today

The following inbound webhook endpoints exist as supported public routes:

  • Intake form submission (/api/public/intake, /api/public/intake-staff) — the entry point for referrals from your own front-ends or third-party form tools.
  • Canvas OAuth callback — used internally by the Canvas integration.
  • Payments — internal Stripe callback for billing events.

Outbound webhooks (AmplifyED → your system) are delivered today by scheduled exports and the CSV/PDF report email rather than HTTP pushes.

What is being scoped

  • Outbound HTTP push for case.created, case.status_changed, case.follow_up_due, case.closed.
  • HMAC signature verification using a per-org shared secret.
  • Retry-with-backoff for non-2xx responses.

Security expectations

Every supported public route already enforces:

  • Zod input validation with explicit max-lengths on every string field.
  • IP rate limiting.
  • Hidden honey-pot fields on intake forms to drop bot traffic.
  • HMAC signature verification on webhook callbacks where applicable.

See Security overview.

How to start a webhook scoping conversation

Email integrations@amplifyed.app with the event types you need and the receiving URL pattern.

Related articles

FAQ

Can I subscribe to all events for one student? The outbound webhook scope (when GA) will support filtering by student ID, case ID, and event type.

Are payloads PII-scrubbed? By default payloads include student IDs and case IDs, not names. Full payloads with names can be enabled per-customer with a signed data processing addendum.

Related