Webhooks
Last updated 2026-06-08
Planned feature. This describes upcoming functionality. The product behavior may change before release.
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
SIS integrations
Who uses it: Districts that want AmplifyED rosters to come from their student information system. When to use it: When you are ready to retire CSV imports as the primary…
Canvas LMS integration
Who uses it: Administrators connecting AmplifyED to a Canvas instance. When to use it: Once during onboarding; revisit if Canvas credentials change or you switch developer keys.…
Security overview
Who uses it: District IT and security reviewers. Purpose: One page summary of AmplifyED's security posture for procurement. US based managed cloud hosting. Single tenant database…
