Integrate APIs

I am about to import an API definition into a low-code platform. It is either an OpenAPI document
or a cURL command. The platform's importer supports only a subset of each format, and if my input
contains anything it does not support, the import fails without the platform telling me what
actually went wrong.
 
Please act as this importer. First work out whether I gave you an OpenAPI document or a cURL
command, then walk through my input using only the matching section of rules below, and tell me
whether it can be imported. If it cannot, point out exactly where the problem is and how I should
fix it.
 
I will attach the OpenAPI file (.json or .yaml), or paste the OpenAPI content or the cURL command
after this message. If I have not provided anything yet, please ask me for it first instead of
guessing.
 
# Part one: rules that apply to an OpenAPI document
 
Judge only by this description, not by the official OpenAPI specification.
 
This importer is not a standard OpenAPI parser; it supports only a subset of the specification.
It walks through paths, then each operation, its parameters, its requestBody and its responses.
There is no error handling anywhere along the way, so a single unsupported construct fails the
whole document and not a single endpoint gets imported.
 
## Conditions that fail the entire import
 
If any one of these is present, nothing gets imported. They are listed in the order the importer
executes, so the ones near the top are triggered first:
 
- The file is not valid JSON or YAML. The platform accepts only the .json and .yaml extensions;
  .yml cannot even be uploaded.
- The document contains a head, options or trace operation, even just one.
- A parameter with "in: query", "in: path" or "in: header" has no schema node. This is common
  with parameters described by "content:", with Swagger 2 style entries such as
  "- name: x, in: query, type: string", and with parameters that are themselves a $ref to
  "#/components/parameters/...".
- Such a parameter has a schema.type other than string, integer, number or boolean.
  Array-typed query parameters (type: array) are by far the most common cause, followed by
  type: object, and by parameters that only declare $ref, allOf, enum or example without a type.
- The document has no info, or info.title is empty. This runs last, so it only surfaces once
  everything before it has passed.
- The document is in fact Swagger 2.0, meaning it contains swagger: "2.0", definitions,
  "in: body", or host/basePath. The importer does not report an unsupported version; it usually
  crashes on a parameter with no schema, or reports success with zero endpoints.
 
Parameters with "in: cookie" are safely ignored and never cause a failure.
 
## Limitations that silently drop content without any error
 
- Request and response bodies only support the application/json,
  application/x-www-form-urlencoded and multipart/form-data content types. For POST, PUT and
  PATCH endpoints, if none of the supported types is present, the endpoint is skipped entirely
  and nothing is reported.
- If one operation declares several supported content types, it is split into several duplicate
  APIs.
- $ref only works in the form "#/components/schemas/XXX". References to external files, to
  "#/definitions/", and to "#/components/responses", "parameters" or "requestBodies" cannot be
  resolved.
- A schema must declare type explicitly or the property is dropped, and type: array must also
  provide items.
- allOf, oneOf and anyOf expand correctly when they hold a single sub-schema, but with two or
  more sub-schemas the whole thing degrades to plain JSON data and the object structure is lost.
- additionalProperties is not expanded, a requestBody on GET or DELETE is ignored, and shared
  parameters declared at the path item level are not merged, so they must be written inside every
  operation.
- securitySchemes and security are not processed at all, and constraints such as enum, nullable,
  pattern and minimum or maximum values are ignored.
- The API name comes from summary rather than operationId; when summary is empty the name is
  assembled as METHOD_path_ContentType.
- A variable inside servers[].url is replaced with the server variable's default. If a variable
  has no default, the url keeps the literal braces and cannot be called after import.
- Only scalar default values are kept. A file field under multipart/form-data is recognised as an
  image or a video only when it declares both type: string and format: binary and its encoding
  contentType names image/* or video/*.
 
# Part two: rules that apply to a cURL command
 
Judge only by this description, not by what curl actually does.
 
The importer never runs the command. It splits it into arguments, takes the request address, the
method, the headers and the body out of it, and builds an API configuration. There is no error
handling here either, so a single unsupported construct means nothing gets imported.
 
## Only these options are read
 
- -X and --request set the request method. Without them, a command carrying a body is treated as
  POST and everything else as GET.
- -H and --header are request headers. They may appear several times and each becomes a header
  parameter.
- -d, --data, --data-raw, --data-binary and --data-ascii are the request body.
- --data-urlencode is a form body. It may appear several times, the values are joined with &, and
  the request is forced to be treated as application/x-www-form-urlencoded.
- -F and --form are multipart form fields and may appear several times.
- --url provides the request address for commands that do not spell it out directly.
 
-F and --data-urlencode take whatever follows them as a value of their own, so the request address
must not come directly after either of them, or it gets swallowed and the import fails with
"url cannot be null". What matters is the option immediately preceding the address, not whether
the address sits at the end of the command: curl -F 'a=1' https://x -F 'b=2' fails just the same.
Putting the address before these options, or naming it with --url, avoids the problem. Every
other option may go on either side of the address.
 
Every option not listed above is silently dropped without affecting the import, for example
-u, --user, -b, --cookie, -L, --location, --compressed, -k, -o, --max-time and --retry.
Options whose own value is an address are dropped together with that value and are never
mistaken for the request URL, for example -x, --proxy, --referer, --resolve, --connect-to, -T
and --upload-file. Basic authentication and cookies in the command therefore never become part
of the API configuration.
 
## Conditions that fail the import
 
- The command has no argument that can serve as the request address at all, and the import fails
  with "url cannot be null". The usual cause is the address being swallowed by a -F or a
  --data-urlencode written in front of it. Note that an address written as ftp://, ws:// or a
  bare api.example.com does NOT fail; it imports as an unusable address and belongs to the third
  group below.
- The request method is HEAD or OPTIONS.
- The value of -X is not one of GET, POST, PUT, PATCH or DELETE, for instance some custom verb.
  Case does not matter; a lowercase post imports fine.
- The command carries a -d body, but its content-type header names something other than
  application/json, application/x-www-form-urlencoded or multipart/form-data. When the command
  contains a -F, that header is not consulted at all and even text/plain does not fail.
- Under application/json the value of -d is not valid JSON. With no content-type header the body
  is treated as application/json, so a form-style -d 'grant_type=client_credentials' fails here
  and needs -H 'content-type: application/x-www-form-urlencoded' added. Reading the body from a
  file with -d @payload.json fails as well, because the file name is taken as the body itself.
- A form body (url-encoded or --data-urlencode) contains a lone percent sign. Every key and value
  is url-decoded once, so -d 'discount=50%' fails with "Incomplete trailing escape (%) pattern"
  and has to be written as discount=50%25.
 
## Limitations that silently drop content without any error
 
- When several body options are present, the first one in the order -d, --data-raw,
  --data-binary, --data-ascii wins, whatever the written order; with several -d options the
  first one wins.
- When -d and --data-urlencode are both present, --data-urlencode replaces the -d body entirely.
- Any -F in the command makes the -d body disappear.
- An address written as ftp://, ws:// or without a scheme does not fail, but imports as an
  unusable address: ftp://a.com/f becomes ftp://a.com and api.example.com becomes the literal
  string null://null.
- The path inside the URL stays fixed in the address and never becomes a bindable path parameter.
- Repeated query parameters keep only the last value, and the order of the query parameters may
  change.
- GET and DELETE carry no body, so a -d on either of them is dropped.
- Repeated -F fields with the same name keep only the last one, whereas repeated names inside a
  URL-encoded body are all kept.
- Url-decoding turns a + inside a form body into a space; %2B is needed to keep the plus sign.
- The value of a -F field can only be text or a file. Even a piece of JSON is kept as a string and
  is never expanded into an object.
- Query parameters, headers and text form fields are all generated as optional strings, and the
  values from the command become their defaults.
- A -F field written as name=@path is the exception: it is recognised as an image, a video or a
  generic file based on the file extension, and it arrives required and unbound, so a value has to
  be bound by hand after importing.
- A cURL command carries no response information, so the import produces the request configuration
  only; the response schema has to be obtained by testing the API once after importing.
 
# What I need from you
 
Use tables wherever a table works, avoid long paragraphs, skip the pleasantries, and do not add a
closing summary. Keep the whole answer under 25 lines.
 
1. Verdict. Say whether I gave you an OpenAPI document or a cURL command, then in one sentence
either "the import will fail because ..." or "it will import, but you will lose ...".
 
2. Must fix. List every place that hits a failing condition from the matching section. Listing only
the first one is not enough, because I would just hit the next failure after fixing it. Use a table
with five columns: location, line, limitation, problem, and how to fix. In the location column use
a path such as paths./users.get.parameters[1] for an OpenAPI document, and a description such as
"the value after -X" for a cURL command; put a dash in the line column when the command is a single
line.
 
If nothing is hit, say so explicitly. For an OpenAPI document, also work through these possible
causes in order and present them in a table with the suspected cause, your reasoning and how I can
verify it: a wrong file extension, an interrupted upload, a Swagger 2.0 document, or a construct
the description above does not cover.
 
3. Worth fixing. Pick the silently dropped content from the matching section that genuinely affects
usability, at most five rows, and leave out the trivial ones. Use a table with five columns:
location, limitation, what gets lost, how to fix, and whether it must be fixed.
 
4. Security note. If my input carries a real credential such as an Authorization header, a Cookie
or an api-key, warn me separately that these values are written into the configuration verbatim and
suggest binding a platform Secret instead. Omit this section when there is none.
 
# Ground rules
 
- Judge only by the importer behaviour described above. A document that is fully compliant with
  OpenAPI 3.0, or a curl command that runs fine in a terminal, can still fail completely, for
  instance because the document carries a single head operation or the command has a lone percent
  sign in a form body.
- Do not refer to the limitations by number or code, such as "rule A4" or "the third item". The
  limitation column must state the limitation itself in one sentence I can understand directly.
- Write fluently and clearly, the way a colleague would explain the problem to me, rather than
  listing keywords. Every cell should be a complete, readable sentence; avoid arrows, ellipses
  and abbreviations.
- The "how to fix" column must be something I can act on directly, naming the exact field or option
  and the target value.
- If the command contains a $'...' string, say how long it is and warn me that the construct is
  unreliable in the first place, so it is worth rewriting with plain single quotes whatever its
  length. Do not quote a precise character threshold; there is none.
- If something simply cannot be expressed in this importer, such as an array-typed query parameter,
  say plainly that it has to be added by hand in the platform after importing. Never invent a
  workaround that changes what the API does.
- Answer in English.