# Ramco Aviation > Ramco Aviation: what the collector reads, how to connect it, its permissions, its certification by Atlantic Agentic Labs and its security posture. Needs onboarding Needs a partner agreement with the vendor, or a client's environment, before it can be built or certified. Ramco Aviation is **built and waiting for onboarding**. Its reference is not public, so the collector is complete (sign-in, read-only reading, four paging styles, changed-since) but refuses to run until our certified forward-deployed engineers map it from Ramco’s aviation API documentation from its API store (signed in), with sandbox credentials, and the OAuth scopes that read only (work orders, task cards, defects and components). developer.ramco.com describes a sandbox after registration; its API store lists nothing until signed in. ## At a glance | Collector | Ramco Aviation, version `1.0.0` | | --------------------------- | -------------------------------------------------------------------------------------------------------------------------- | | Reads | Ramco Systems: Ramco Aviation maintenance and engineering APIs ([the vendor's documentation](https://developer.ramco.com)) | | Family | Aviation | | Kind | Maintenance | | Ways to connect | OAuth approval, Access token | | Scopes | - Read: | | Read only | Yes, except: \[object Object] | | Vendor's API can move money | No | | Personal data | Employment | | Hosts it may contact | Only the hosts on your deployment's allow-list (`*`: the host is the one you give it) | | Vendor API versions | the licensed reference named in the source's api.spec_ref | | Lowest engine version | `0.46.0` | ## What it reads - Once onboarded: Ramco maintenance records read in place, sandbox first, then production. - Only the lists the mapping names, each as a *collection*: a path, the field that is the record’s id, the list’s key in the response, the fields joined for the title, the change-time field, and how the API pages (`none`, `next_link`, `offset`, `cursor` or `page`). - Each item becomes one record, keyed `/`. Items with no id are skipped. - Before onboarding it reads nothing: the source fails at once with a message naming the reference it needs and what onboarding unlocks. ## How to connect 1. Ask us to onboard it. We need Ramco’s aviation API documentation from its API store (signed in), with sandbox credentials, and the OAuth scopes that read only (work orders, task cards, defects and components), a credential that can only read, and the host it is served on. 2. We write the `api` block from that reference. The block names the reference (`spec_ref`), the https `base_url`, one sign-in (`api_key_header`, or `token_url` for OAuth client credentials) and the collections. Example, with invented values: ```yaml source: kind: ramco label: internal api: spec_ref: "Ramco aviation API documentation, release and section, as licensed" base_url: https://api.example-operator.aero/v1 # the client's own host api_key_header: X-Api-Key # or token_url: https://login.example-operator.aero/token collections: - {path: /items, items: data, id: id, title: [number, title], updated: modified, since_param: modifiedSince, paging: offset, page_param: offset, size_param: limit, size: 200, kind: Maintenance} ``` 3. The credential reaches the collector as environment variables named in the source (`api_key_env`, or `client_id_env` and `client_secret_env`); your deployment fills them from its own secrets store, so neither the credential nor the records pass through LightHouse. 4. In LightHouse the card reads **Needs onboarding** until the mapping is in; connect it as **Read**. ## Permissions - `GET` only. The one `POST` is the OAuth token request to the `token_url` you name, listed in the manifest’s `read_operations`; an API-key source sends no `POST`. - A token whose granted scope names a write (create, update, delete, cancel, book, issue, ticket, check-in, manage, admin, `*`) is refused before it is used, and the credential check says so. - Your deployment refuses to store this credential at read and write, whatever its policy allows. - Give the vendor a credential that can only read; this collector does not depend on that, but the vendor’s audit trail will. ## Limits - Inert without `api`; the mapping is checked before anything runs (`api.spec_ref`, an https `base_url`, one sign-in, at least one collection, an absolute path and id for each). - Changed-since reading exists only where the reference gives a `since_param`; without one every run reads the whole list again. - A list is read up to `max_pages` pages (500 by default); a listing that does not end fails rather than loops. - Requests are paced (`delay_s`, one second by default); `429` and `5xx` are retried with backoff and `Retry-After`. - It is built from the engine’s generic adapter. Nothing about the vendor’s payload is assumed until the licensed reference is in hand. ## Data handling - Records are read and indexed inside your deployment. LightHouse receives ids, hashes and counts, never a record. - Nothing is cached raw, and a failure names the host, never the URL (a URL can carry a record locator). - By default these are left out of every record: travel document numbers and dates of birth, and health or disability special service requests. Contact details are not left out by default for a maintenance system, whose records name engineers and sign-offs; add the fields that hold them to `exclude_fields`. `exclude_fields` adds paths; `keep_fields` takes a default back by its exact name, and that choice is your record of the decision. - The spec reference is stored on each record’s metadata (`spec_ref`), so a question can be traced to the document the mapping came from. ## Troubleshooting | What you see | What it means | What to do | | ------------------------------------------------------------------------- | ----------------------------------------------------------- | -------------------------------------------------------------------------------------- | | ``Ramco Systems: needs onboarding. Supply `api` from ...`` | No `api` block yet | Ask us to onboard it | | `unknown api keys: [...]` | The `api` block has a key the adapter does not know | Use only `spec_ref`, `base_url`, `token_url`, `scope`, `api_key_header`, `collections` | | `api.spec_ref names the licensed reference the mapping is from` | No reference is named | Name the reference and its release | | `api names one of token_url (OAuth client credentials) or api_key_header` | Both or neither sign-in is given | Give exactly one | | `credential variable 'X' is not set` | The deployment has not filled the variable the source names | Set it from your secrets store | | `the credential grants writes; this release reads only: ...` | The token’s scope names a write | Issue a credential limited to reading | | `GET host: HTTP 401` | The vendor refused the credential | Check it has not expired or been revoked | | `more than N pages; raise max_pages` | The listing did not end | Check the paging fields in the mapping | ## Certification Each entry is a run by Atlantic Agentic Labs, newest first. Only a run against the vendor’s sandbox or a client environment certifies a collector; a certification lasts six months, or less if the vendor publishes an API version the collector does not list. See [How collectors are certified](/collectors/certification/). | Date | Collector | Engine | Vendor API | Method | Expires | | ---------------- | --------- | -------- | ------------------------------------------------------------------------- | ----------------------------------- | -------------- | | 10 November 2026 | `1.0.0` | `0.47.0` | the licensed reference named at onboarding (api.spec_ref); none is public | Fixtures only: built, not certified | Not applicable | ## Security posture From the collector’s last scan on the default branch. What each line means, and what blocks a release: [Security posture](/collectors/security/). | Last scanned | 10 November 2026 | | -------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Critical findings | 0 | | High findings | 0 | | Medium findings | 0 | | Low findings | 0 | | Info findings | 0 | | Release blocked | No | | Network allow-list check | Pass | | Read-only behavioural test | Pass | | SBOM (CycloneDX) | Produced | | Dependency licences | Pass | | Scanners | bandit 1.9.4, semgrep 1.181.1, pip-audit 2.10.1, osv-scanner 2.7.0, cyclonedx-py 7.5.0, pip-licenses 5.5.5, gitleaks repository job aal-secrets, hosts_check tools/hosts_check.py, read-only test pytest -m read_only | Source: https://docs.atlanticagenticlabs.com/collectors/catalogue/ramco/