Skip to main content

Input Parameters

At a Glance​

  • Input parameters use simple name–value pairs.
  • SDK sets parameters when screens load.
  • Direct API calls require explicit parameter construction.
  • Lists use comma-separated values.
  • Lists of objects use tilde-suffixed indexes.
  • Optional headers add device and user context.

Use this section when your integration requires direct API calls or custom parameter construction.

Air Doctor’s API uses simple name–value pairs for all input parameters. When you integrate through the screen compositions in other sections, the SDK attaches the correct parameters based on the fields on the screen. When you call an endpoint directly, you must construct the parameter list yourself according to the conventions in this section.

Naming Conventions​

Air Doctor’s parameter model uses three input types.

  • Single values – Provide each value as one parameter. For example, to book an appointment you send doctorId, date, and time.
  • Lists of primitives – When the OpenAPI schema specifies a list of simple values (such as a list of specialty identifiers), submit the values as a comma-separated string. For example: specialties=cardiology,dermatology,pediatrics.
  • Lists of objects – For objects that contain multiple fields, append a tilde and an index to each related field. For example, to send two date-time pairs name the fields date~1, time~1, date~2, time~2. Fields with the same suffix (such as ~1) form one object. The suffix index defines object order.

These suffix conventions enable a flat parameter model without JSON bodies or DTOs. The OpenAPI documentation includes examples that define each required field and its name.

Parameter Sources​

When screens assemble through the server‑driven UI model, the SDK sets input parameters based on the fields on the page and sends all the visible and invisible fields that the model defines. Invisible fields can store context.

Standard Request Headers​

In addition to input parameters, API calls can include the optional headers that convey device and user context. These headers are not required for every call, yet supplying the headers enables richer features (such as video consultations) and improves the user experience.

Parameter Source Flow​

                      +---------------------------+
                      |   Server-Driven UI Model  |
                      +-------------+-------------+
                                    |
                                    v
                      +---------------------------+
                      |   Page Field Definitions  |
                      |   (visible + invisible)   |
                      +-------------+-------------+
                                    |
                     SDK reads field definitions
                                    |
                                    v
                      +---------------------------+
                      |   SDK Parameter Assembly  |
                      |   - visible fields        |
                      |   - invisible fields      |
                      +-------------+-------------+
                                    |
                          Parameters for request
                                    |
                                    v
                      +---------------------------+
                      |     Air Doctor Backend    |
                      +---------------------------+

Request Headers​

The table defines each supported header, its purpose, and its accepted values.

HeaderPurposeAccepted Values
X-CameraIndicates whether the user grants camera access. The server assumes that after access is denied the user cannot grant access again without system changes; the server presents a popup with instructions.granted; query; denied
X-MicrophoneIndicates whether the user grants microphone access for audio in video calls.granted; query; denied
X-LocationIndicates whether the user grants GPS access. The value supports nearby doctor suggestions.granted; query; denied
X-CoordinatesSpecifies current latitude and longitude. Explicit coordinates prevent a new prompt for location access.Comma-separated pair, for example: lat=12.34,lng=-56.78
X-DirectivesProvides special application instructions. Refer to Level 2 documentation for the list of available directives.For example: embedded, desktop
X-PushesIndicates whether push notifications are allowed.granted; query; denied
X-Push-TokenSupplies the push notification token, if available.Token string
X-VersionIdentifies the Air Doctor SDK version. If you call the API directly, set this value to the SDK version you emulate.For example: 20260115
X-TimezoneSpecifies the user’s time zone for accurate timestamp conversion.IANA identifier, for example: Europe/Paris
X-Device-TimeSupplies the client’s current Unix time. When both X-Timezone and X-Device-Time are present, X-Timezone takes priority. If neither value is provided, the server uses the last known time zone or UTC.For example: 1763157148

Tokens are also available through headers and parameters. See Access Token Handling for information about token acquisition and transmission.

By following these conventions, you ensure that the Air Doctor server correctly interprets your API calls and includes relevant device capabilities and user context.

Common Mistakes​

caution
  • Mixing tilde indexes across unrelated objects.
  • Sending JSON instead of flat parameters.
  • Omitting invisible context fields in server-driven UI screens.