FAA Aircraft Ownership & Registration Change Monitor

Track the FAA aircraft you already know by N-number. Get the current public registration, owner name, aircraft model and certificate expiry, then run the same watchlist again to see verified changes with before-and-after values.

Use it for fleet registration reviews, ownership-record monitoring and certificate expiry reminders. It reads the official FAA aircraft registry download. It does not discover sales leads or search by owner name.

Get your first results

1. Replace the sample N-numbers in FAA aircraft watchlist with your aircraft.
2. Give the list a Monitor key, such as managed-fleet. Keep this key for future checks.
3. Leave Mode as snapshotAndChanges and Baseline mode as emitSnapshot.
4. Use 512 MB, a 300-second timeout and a $1 maximum charge for this example. Two verified aircraft cost $0.056. Open Observations and changes when it finishes.

{
  "monitorKey": "managed-fleet",
  "aircraft": [
    {"nNumber": "N12345", "externalId": "fleet-001"},
    {"nNumber": "N221DG", "externalId": "fleet-002"}
  ],
  "expiryWindowsDays": [365, 180, 90, 30],
  "mode": "snapshotAndChanges",
  "baselineMode": "emitSnapshot"
}

You can also enter a simple list: ["N12345", "N221DG"]. The sample numbers are public registry lookups, not aircraft endorsed by or affiliated with this Actor.

The first verified check returns a BASELINE for each aircraft. A later check returns a CHANGE when facts or expiry thresholds change, or a SNAPSHOT when the current observation is unchanged. Check source_data_as_of to see the date of the FAA export; the result is not a live aircraft movement feed.

Choose the right workflow

Goal	Settings	What to expect
Export current registrations	snapshotAndChanges, emitSnapshot	A current observation for every verified aircraft on each run
Receive changes for a stable fleet	changesOnly, emitSnapshot	Initial baselines, then changes and diagnostic rows
Start monitoring without initial alerts	changesOnly, storeOnly	Baselines saved silently; subsequent changes still appear
Review certificate expiry	snapshotAndChanges, thresholds such as [90, 30]	Expiry date and days remaining, plus threshold events

A daily run with the same Monitor key is usually appropriate for this bulk source. Add an Apify Schedule if you want automatic checks. The Actor does not create schedules, send email or configure webhooks for you.

In changesOnly mode, an empty Dataset can be a successful check with no changes. Open Every input status (CHECKS) and Run summary (RUN_SUMMARY) to confirm what happened. Do not treat an empty Dataset as evidence that aircraft disappeared.

Inputs

Field	How to use it
aircraft	1–2,000 N-number strings or objects with nNumber and optional externalId. Case, spaces and an omitted N-prefix normalize automatically.
monitorKey	A watchlist name using 1–80 letters, digits, underscores or hyphens. Use a different key for an independent comparison history.
expiryWindowsDays	1–10 distinct integer thresholds from 1 to 1,825 days. Default: 365, 180, 90 and 30.
mode	snapshotAndChanges includes unchanged observations. changesOnly returns baselines, changes and diagnostics. The Console prefill uses the first; the API default is the second.
baselineMode	emitSnapshot returns the first observation. storeOnly saves it without a baseline row, including aircraft added later.

Invalid entries receive their own error without blocking valid aircraft. Duplicate N-numbers are compared once; CHECKS retains every submitted input, its original index, duplicate reference and external ID. Dataset rows represent the unique comparison, so use CHECKS to map duplicates back to your system.

Adding an aircraft creates its own baseline. Removing it from the list prunes its stored comparison state after a verified source run. Adding it back later starts a new baseline. Use one complete watchlist per key and avoid overlapping runs.

Results and change events

The default Dataset contains N-number, manufacturer, model, serial number, registered owner name, coarse mailing location, registration status, certificate dates, days to expiry and observation metadata. Download results as JSON, CSV, Excel or another supported format from Apify's export menu.

Use Aircraft observations for fleet exports, Certificate expiry for date reviews, Change events for before-and-after values and Verification details for errors. The Change events view expands event types; filter record_type=CHANGE when your downstream workflow should receive change alerts only.

Events include owner and registration-status changes, certificate-date changes, deregistration, N-number reassignment, expiry-window entry and certificate expiry. Thresholds use the UTC observation date, so a date-based alert can occur even if the FAA export itself is unchanged.

Example excerpt from synthetic test data, not actual ownership history:

{
  "record_type": "CHANGE",
  "status": "SUCCESS",
  "source_id": "N221DG",
  "monitor_key": "synthetic-example",
  "change_types": ["OWNER_CHANGED"],
  "changes": {
    "owner_name": {
      "before": "PREVIOUS SYNTHETIC OWNER",
      "after": "SYNTHETIC AVIATION LLC"
    }
  }
}

Each observation includes a source URL, source date, observation time, schema_version, fingerprint and event_id. An N-number can be reassigned to a different aircraft. The Actor compares manufacturer code and serial number and emits N_NUMBER_REASSIGNED without inventing a sale between different aircraft.

Understand verification statuses

Status	Meaning	Effect on comparison history
SUCCESS	Public record and required comparison fields verified	Save the verified observation
NOT_FOUND	Number absent from validated public MASTER and DEREG files	Record public absence
PARTIAL	Selected information is ambiguous, malformed or unavailable	Keep the previous good observation
SOURCE_FAILED	Source download, freshness, schema or integrity could not be verified	Keep the previous good observation
INVALID_INPUT	Submitted entry is not a supported N-number input	No history update
SKIPPED in CHECKS	The run budget or pricing configuration prevented the check	No history update or Actor event fee

NOT_FOUND does not prove deregistration or nonexistence. FAA allows owners to withhold information from public dissemination. Missing owner information is reported as PARTIAL, not an ownership change. A public record that reappears gets a new verified baseline, not an unsupported re-registration claim.

Current MASTER records take priority over historic deregistrations. Stale archives over seven days old, timestamp rollbacks and large record-count drops fail source validation. A registry owner-name change is not proof of a sale, legal title, beneficial ownership or airworthiness; verify consequential decisions with FAA.

API and AI agent use

POST the input above with your Apify authorization header to:

https://api.apify.com/v2/acts/automa-flow~faa-aircraft-registration-change-monitor/runs?timeout=300&memory=512&maxTotalChargeUsd=1

Use an asynchronous run and wait for completion. Then read the Dataset, CHECKS and RUN_SUMMARY from its output links. For webhooks, handle both successful and failed runs, and inspect the per-input statuses before changing your own records. Deduplicate delivered observations by event_id.

For automatic daily checks, this schedule API body runs the example watchlist at 07:00 America/Chicago. Replace the watchlist and key before creating it in your own account:

{
  "name": "faa-managed-fleet-daily",
  "isEnabled": true,
  "isExclusive": true,
  "cronExpression": "0 7 * * *",
  "timezone": "America/Chicago",
  "actions": [{
    "type": "RUN_ACTOR",
    "actorId": "Nmi1L2VxdLWROcUQB",
    "runInput": {
      "body": "{\"monitorKey\":\"managed-fleet\",\"aircraft\":[\"N12345\",\"N221DG\"],\"mode\":\"changesOnly\",\"baselineMode\":\"emitSnapshot\",\"expiryWindowsDays\":[365,180,90,30]}",
      "contentType": "application/json; charset=utf-8"
    },
    "runOptions": {"build": "latest", "timeoutSecs": 300, "memoryMbytes": 512, "restartOnError": false}
  }]
}

Optional webhook API body for your own receiver; replace the example URL:

{
  "eventTypes": ["ACTOR.RUN.SUCCEEDED", "ACTOR.RUN.FAILED"],
  "condition": {"actorId": "Nmi1L2VxdLWROcUQB"},
  "requestUrl": "https://your-service.example/faa-run"
}

For an authenticated Apify MCP client, select this Actor with:

https://mcp.apify.com?tools=automa-flow/faa-aircraft-registration-change-monitor

Example prompt: “Check N12345 and N221DG under managed-fleet. Report verified registration changes and aircraft entering the 30-day expiry window.”

Private access requires the owning account or an authorized collaborator. The Actor uses limited permissions for its own persistent storage.

Runtime, limits and pricing

Every source check downloads and validates the complete FAA archive, even for one N-number. Combine aircraft into a watchlist instead of starting one run per aircraft. No browser or proxy is needed. Cloud validation at 512 MB includes the actual two-aircraft Console example; allow several minutes for a full check.

Pay per event: $0.05 per successful watchlist run + $0.003 per unique verified N-number. Platform usage is included in this price; there is no extra fee per Dataset row. The Actor's Pricing tab shows the effective configuration.

Unique verified aircraft	Maximum Actor event fees per run	30 successful runs
1	$0.053	$1.59
2	$0.056	$1.68
10	$0.080	$2.40
100	$0.350	$10.50
1,000	$3.050	$91.50
2,000	$6.050	$181.50

The verified-aircraft-check event includes a first baseline, an unchanged observation and confirmed public absence (NOT_FOUND). You pay for a verified check, even when changesOnly produces no Dataset rows. The verified-watchlist-run fee applies only when at least one such check is saved and available. If no checks can be verified, both event fees are zero. Partial/failed checks, invalid inputs, duplicates and retries do not add fees.

Before downloading FAA data, the Actor checks the budget for every unique valid number in the input. A smaller budget produces BUDGET_EXCEEDED and a SKIPPED receipt for each valid input, with no source request, fee or history change. A $1 limit supports up to 316 unique numbers. For 2,000 use at least $6.05; $7 leaves a small allowance. The input limit bounds the event bill at $6.05 even when no explicit charge limit is supplied. The actual bill is lower when some checks are partial. A budget refusal does not claim the FAA source failed.

RUN_SUMMARY reports billable_check_count, charged_event_counts, charged_amount_usd and billing_status. If a charge response is ambiguous, the affected count and amount are null, not a false zero; inspect the original run's Apify charge record. No recovery run retries that charge. If Apify accepts only part of a charge, verified data remains available and unpaid work is not billed again during recovery.

The input limit is 2,000 entries. Very large change histories can hit the 8 MiB state-and-delivery limit earlier; split the watchlist if the Actor reports that limit. Source download and parsing share a 240-second deadline. The work phase has a 280-second limit, independent of a longer user timeout. Memory is fixed at 512 MB. Download, expanded-file and individual-record limits bound archive parsing.

Privacy and interrupted runs

Only watched public records are retained. Street addresses are omitted, raw ZIP files are temporary, and suppressed personal information is not reconstructed. Owner and co-owner names plus coarse mailing location remain personal data in some cases. Set appropriate Dataset retention and delete unused monitor state.

Comparison state lives in faa-aircraft-registration-change-monitor-state under FAA_MONITOR_STATE_V2_<hash-of-monitorKey>. Output delivery uses a saved journal; recovery can repeat an event_id, so consumers must deduplicate it. A recovery-only run reports recovery_only=true; run again to check fresh source data. Recovery-only delivery has no additional Actor event fees, including the run fee. The original billing receipt is retained as original_billing. An unfinished charge is never retried; unattempted charges for that delivery are waived.

A hard crash or timeout may leave a safety lock in faa-aircraft-registration-monitor-locks. Before deleting the marker for the affected Monitor key, stop every run using that key. Keep the baseline and pending output in the key-value store. Restarting without clearing an uncertain lock fails explicitly rather than allowing conflicting writers.