FAA document integration planning
FAA 8130-3 API: Integration Scope and Availability
No. There is no public FAA 8130-3 extraction API this week. The catalog as of 12 September 2026 exposes extract_easa_form1 only.
Define samples, expected fields and a named review owner before you treat ChatGPT transcription as a Doana FAA product. Contact is the next step for an unavailable extraction operation, not a hidden FAA tool in OpenAPI.
Public catalog as of 12 September 2026: extract_easa_form1 only.
No public FAA 8130-3 API
No dedicated FAA 8130-3 extraction operation is published today. There is no FAA output schema in OpenAPI and no REST extract endpoint for either form. Call tools/list to confirm.
The FAA’s export airworthiness approval pages remain the legal reference for the tag itself. Extraction, if it existed, would still not establish release validity or installation eligibility. Wait for a published FAA tool name and schema before writing FAA extraction code.
- Use the EASA integration today only for EASA Form 1.
- For FAA 8130-3, contact Doana with redacted samples, expected fields and validation rules.
- Do not treat dual-release packets as automatically in scope.
ChatGPT transcription is not a Doana FAA job
If the chat environment can attach the 8130-3, ChatGPT can copy visible block text into a table with a source column. Unreadable characters should stay marked unreadable. That transcript is a reading aid. It is not get_extraction_result, not documentType easa_form_1, and not a Doana FAA job.
Doana will not certify that transcription as an API product. Confidence scores from an EASA job must never be copied onto FAA rows. Dual-release packages need a human to say which certificate is in play before any downstream mapping begins.
Evaluate an FAA extraction project
Build the evaluation around the actual tags you receive, not a generic block map. Provide redacted examples, scan quality, multiple items and differing release statements. Agree how part numbers, serial numbers, quantities and remarks should be represented if a schema is later offered.
Include unreadable fields in acceptance tests. Define who reviews the source before output reaches operational systems. A field mapping alone is insufficient to validate the legal meaning of a release. Keep that review owner named in the project, not in a prompt.
An EASA prototype is not FAA support
You can exercise OAuth, create_mcp_upload, job polling and get_usage with an EASA Form 1 today. That prototype validates transport. It is not proof that an 8130-3 will parse, that documentType will be anything other than unknown, or that uncertainFields will be meaningful for FAA blocks.
If you send an FAA-only file to extract_easa_form1, treat documentType unknown or a failed_refundable / failed_charged job as an unresolved receiving item. documentType unknown is usually a succeeded job with no Form 1. Do not reconstruct FAA blocks from chat. Discuss dual-release or ambiguous certificates with Doana using redacted samples rather than assuming similar layouts are interchangeable.