Show engine details

Everything you need to build a request for one engine: what it asks for to log in, and what it can retrieve. This is the endpoint that removes the guesswork, and the one worth calling before every integration change: - **`parameters`** — the credentials and inputs this engine needs, as an OpenAPI 3.0.3 Schema Object. It is a form description: field names, types, whether each one is required, and the labels to show. Build your input from it rather than hardcoding *username + password*, because institutions do change what they ask for. - **`features`** — every feature the engine offers, each with the configurations it accepts (a date range, a document type, a depth of history). What you send in `features` at execution time is chosen from here. - **`events`** — the events this engine raises, so you know which webhooks are worth subscribing to for it. - **`action_required_frequency`** — how often this engine stops mid-run to ask your customer something. `always` means every execution will need a person: starting one without `customer_interaction_available` is rejected outright. - **`engine_restrictions` and `engine_issues`** — known limits of the source in plain language, such as history that is only available for a certain period or data that cannot be read at certain hours. A `503` means the engine exists but is not available right now; a `404` means the reference does not exist or is not enabled for your application. **Cache this too, and refresh it on a schedule rather than before every execution.** An engine's form changes when the institution changes it — rarely, and never in the seconds between two of your calls. What you must not do is hardcode the form and stop asking altogether: then the change arrives as a wave of failed logins instead of a new field. > This endpoint needs to be executed with an app secret, so should always be used in server side without exposing the secret to customers.