A Developer API, Webhooks, and Integrations for Your Whole Operation
Developer API, Webhooks & Integrations is part of AviationAlley. An aviation operation never runs on one system. The crew planner exports to a spreadsheet, the books live in QuickBooks, dispatch pings a Slack channel, and the HRIS needs a feed of who's current — and most flight-ops tools leave you to bridge all of it by hand. AviationAlley is built so its operational data and events are reachable programmatically: a public REST API v1 with scoped bearer tokens and rate limiting, HMAC-signed outbound webhooks with a per-attempt delivery log, chat and email notifications, and finance bridges to QuickBooks Online and integrated payments. This page describes the aviation operations software API and integrations layer as it is designed for the founding cohort. AviationAlley is a pre-launch product opening to a founding cohort of operators across 12 FAR Parts; the integrations described here are the developer surface being built with that cohort, not a generally available platform with adoption numbers behind it. Request early access through the AviationAlley contact page to join.
The problem: your ops data is trapped in one more silo
An operator under any FAR Part — a Part 142 training center, a Part 135 charter, a Part 121 carrier, a Part 145-leaning maintenance shop — runs on more than a single application. Pilots and trainees live in the ops platform, payroll and invoices end up in QuickBooks, leadership wants alerts in Slack or Teams, and a parent airline's HRIS or a third-party compliance dashboard needs a clean read of who is current and what is due.
When the ops system has no API, every one of those connections becomes a manual export, a copy-paste, or a brittle screen-scrape that breaks the next time a page changes.
Events are worse than records. A booking gets completed, a work order closes, an invoice is paid, a compliance item goes overdue — and the systems that should react find out late, because there is no signal.
Someone notices the change on a dashboard hours later and forwards an email. The longer that lag, the more a crew shows up to a tail that's been grounded, or an accounts-payable team double-pays an invoice that was already reconciled.
Finance is the silo that hurts most. Aviation revenue arrives as contract invoices, ACH, cards, and international wires — and it has to land in the accounting system the bookkeeper already uses.
Without an invoice bridge and a real card/ACH rail wired into the ops platform, every paid invoice is re-keyed by hand, and the books drift out of sync with the operation that generated them.
- No API means every integration is a manual export, copy-paste, or fragile scrape that breaks on the next UI change
- External systems — HRIS, fleet management, compliance dashboards — can't pull a clean, scoped read of trainees, crew, or compliance
- State changes (booking completed, work order closed, invoice paid, compliance overdue) reach other tools late, by email, not in real time
- Chat tools like Slack and Teams stay out of the loop, so the people who should act on an alert see it last
- Paid invoices get re-keyed into QuickBooks by hand, so the books and the operation drift apart
- Card, ACH, and wire payments live outside the ops platform, so reconciliation is a separate, error-prone hunt
How AviationAlley's API and webhooks are built to work
AviationAlley exposes a versioned public REST API (v1) designed for the systems around it — HRIS, fleet management, and third-party compliance dashboards. Requests authenticate with a scoped bearer token, and each token is designed to carry only the read scopes an integration actually needs, so a payroll feed that reads crew can't also read invoices.
Read endpoints span the operational record set the founding cohort works in — trainees, bookings, flight log, crew, MEL, cargo, fatigue, operating bases, and credentials — and use keyset pagination with a per-request limit so a large pull stays predictable. The API enforces a per-key rate limit and returns standard rate-limit headers and a clear retry signal when a caller goes over, so an integration can back off cleanly instead of being cut off.
Outbound webhooks are designed to push events the moment they happen rather than make systems poll for them. When a booking is created, updated, completed, or cancelled, a work order moves, an invoice is created, paid, or voided, a trainee record changes, or a compliance item goes due-soon or overdue, AviationAlley is built to POST a JSON event to whichever endpoints a center has subscribed.
Every delivery carries an HMAC-SHA256 signature computed over the exact request body, plus event and delivery headers, so the receiver can verify the message genuinely came from AviationAlley and was not tampered with — the verification recipe is published in the webhook docs in Node, Python, Ruby, PHP, and Go.
Because delivery to a remote endpoint can fail, every attempt is designed to be recorded, and failed deliveries are automatically retried on a backoff schedule before the system gives up. The delivery log captures the response status, the response body, and how long the call took for each attempt, so an operator can see exactly which events reached a subscriber and which didn't — and a test-fire from the integrations screen confirms a new endpoint is wired correctly before real traffic flows.
The event vocabulary is the same one the docs render, so what you subscribe to and what you can verify never drift apart.
- Public REST API v1 with scoped bearer tokens — each token carries only the read scopes its integration needs
- Read endpoints across trainees, bookings, flight log, crew, MEL, cargo, fatigue, operating bases, and credentials
- Keyset pagination with a per-request limit, so large pulls stay predictable and resumable
- Per-key rate limiting with standard rate-limit headers and a retry signal, so callers back off cleanly
- HMAC-SHA256-signed outbound webhooks over the exact request body, with event and delivery headers for verification
- A documented event vocabulary covering bookings, work orders, invoices, trainees, and compliance state changes
- A per-attempt delivery log — response status, body, and duration on every try — with automatic backoff retries and a test-fire to validate an endpoint
What's included: chat, email, QuickBooks, and payments
Beyond the raw API, AviationAlley is built to push the alerts that matter into the tools an operation already lives in. A center can connect a Slack and/or Microsoft Teams incoming webhook, and notifications are formatted to render natively in each — so the people who should act on an overdue compliance item or a paid invoice see it in the channel they already watch, not buried in a dashboard nobody opened.
The same notification layer also sends email digests through Resend, so an operator who lives in their inbox gets a clean summary rather than a feed of one-off alerts.
On the finance side, AviationAlley is designed to bridge to QuickBooks Online over OAuth: a center authorizes the connection once, and trainees and simulator-booking invoices can sync across so the books reflect the operation that generated them instead of being re-keyed by hand.
The connection status — including the QuickBooks company it's linked to — is visible from the billing side, so it's clear whether the bridge is live.
For taking payment, AviationAlley uses connected payout accounts, so each center can be paid directly into its own account rather than having funds flow through AviationAlley's balance.
Invoices generate a hosted checkout link that accepts both card and bank (ACH) payment, and when a payment clears, the platform is designed to mark the invoice paid and record which method was used — closing the loop between a paid invoice and a reconciled book without a manual hunt.
- Slack and Microsoft Teams notifications via incoming webhooks, formatted to render natively in each
- Email digests through Resend for operators who work from their inbox
- QuickBooks Online bridge over OAuth — connect once, sync trainees and booking invoices, with visible connection status
- Integrated payments with connected payout accounts, so each center is paid into its own account
- Card and bank (ACH) payment on a hosted checkout link generated per unpaid invoice
- Paid invoices are marked paid with the payment method recorded, closing the reconciliation loop
Frequently asked questions
Is the AviationAlley API available today?
Not as a generally available product. AviationAlley is a pre-launch platform opening to a founding cohort of operators across 12 FAR Parts, and the REST API v1, webhooks, and integrations described here are the developer surface being built alongside that cohort. Request early access through the AviationAlley contact page — there are no public adoption numbers or pricing to quote yet.
How do webhook signatures and failed deliveries work?
Every outbound webhook is signed with HMAC-SHA256 over the exact request body, and the verification recipe is published in the docs in Node, Python, Ruby, PHP, and Go so your receiver can confirm a message genuinely came from AviationAlley. Each delivery attempt is logged with its response status, body, and duration; failed deliveries are retried automatically on a backoff schedule, and a test-fire from the integrations screen lets you validate a new endpoint before real traffic flows.
Which payment and accounting tools does it connect to?
It's designed to bridge to QuickBooks Online over OAuth for syncing trainees and simulator-booking invoices, and to take payment through connected payout accounts so each center is paid into its own account. Invoices generate a hosted checkout link that accepts card and bank (ACH) payment, and a cleared payment is recorded back against the invoice. Chat alerts go to Slack and Microsoft Teams via incoming webhooks, with email digests through Resend.