twilio / twilio-oai

The Twilio OpenAPI Specification

Twilio's OpenAPI Specification

This repository contains OpenAPI documents for Twilio's API.

Files can be found in the json/ and yaml/ directories.

What is OpenAPI?

From the OpenAPI Specification:

The OpenAPI Specification (OAS) defines a standard, programming language-agnostic interface document for HTTP APIs, which allows both humans and computers to discover and understand the capabilities of a service without requiring access to source code, additional documentation, or inspection of network traffic. When properly defined via OpenAPI, a consumer can understand and interact with the remote service with a minimal amount of implementation logic. Similar to what interface documentation have done for lower-level programming, the OpenAPI Specification removes guesswork in calling a service.

Project Status

This project is currently in GA. We expect the spec to be accurate, and it is currently in active development. If you've identified a mismatch between Twilio's API behavior and this specification, please open an issue.

Contributing

Because this document is used across Twilio's whole API development experience, these documents are automatically kept up to date and used to validate Twilio API requests.

twilio-oai's Issues

Unable to export the Open API Specification to Azure APIM

Issue Summary

Unable to export the Open API Specification to Azure APIM #49

Steps to Reproduce

1. Sign up for Azure Portal
2. Create an APIM instance
3. Navigate to API and select create API
4. Select Open API specification API
5. Enter the GitHub URL https://github.com/twilio/twilio-oai/blob/main/spec/json/twilio_ip_messaging_v2.json
6. See the error.

Screenshot

Technical details:

• twilio-oai version:
• open version:

Hi!

Oops

Test Issue

Adding a test issue 🙏

Support Encoding Object

Issue Summary

As part of the 3.0.1 OpenAPI spec there's the ability to give further information about the behaviour of individual properties
https://github.com/OAI/OpenAPI-Specification/blob/main/versions/3.0.1.md#encoding-object

This is useful for crafting requests and mocking services to more accurately replicate the live services and SDKs.

I've been looking into the notify arena so my examples are from there

Steps to Reproduce

1. Import the notify spec into https://editor.swagger.io/
2. Craft a notification request POST /v1​/Services​/{ServiceSid}​/Notifications with multiple Identities
3. Resulting payload looks like Identity=string1,string2
4. Edit the spec to have

            encoding:
              Identity:
                style: form

5. The payload now looks like Identity=string1&Identity=string2 (this matches how Twilio Java SDK crafts the request)

This is one simple example, but there's many other properties that could benefit from this treatment, (ie objects encoded in application/json) which would help with other services like prism when they also support encoding - see stoplightio/prism#1622

Incorrect type for `latitude` and `longitude` fields

According to the docs here:
https://www.twilio.com/docs/phone-numbers/api/availablephonenumberlocal-resource

The latitude and longitude fields are strings, e.g.:

[...]
      "latitude": "19.720000",
[...]
      "longitude": "-155.090000",

However, the OpenAPI spec specifies them as type number:
https://raw.githubusercontent.com/twilio/twilio-oai/main/spec/json/twilio_api_v2010.json

[...]
          "latitude": {
            "description": "The latitude of this phone number's location",
            "nullable": true,
            "type": "number"
          },
[...]
          "longitude": {
            "description": "The longitude of this phone number's location",
            "nullable": true,
            "type": "number"
          },
[...]

I think this might be what's causing errors in the Go SDK, e.g. in twilio-go:

json: cannot unmarshal string into Go struct field ApiV2010AvailablePhoneNumberLocal.available_phone_numbers.latitude of type float32

See: twilio/twilio-go#120

What date formats can we use in the DateSent parameter?

There is a "YYYY-MM-DD" format(with '2009-07-06' example) in the description, but various date formats are listed on the website in the examples. I've tested various formats and they all work(2020-12-12T10:53:43-08:00, 2020-12-12T10:53:43Z, 2020-12-12T10:53:43.000-0800, 2020, 2020-12).
So what date formats can we use in the DateSent parameter?

- description: 'The date of the messages to show. Specify a date as `YYYY-MM-DD`
          in GMT to read only messages sent on this date. For example: `2009-07-06`.
          You can also specify an inequality, such as `DateSent<=YYYY-MM-DD`, to read
          messages sent on or before midnight on a date, and `DateSent>=YYYY-MM-DD`
          to read messages sent on or after midnight on a date.'

Add tags to specs

Issue Summary

Please add tags to the specs to make them easier to navigate when using tools like Swagger UI.

For example, this is the current untagged Verify spec when rendered in Swagger UI:

https://johnchaffee.wiki/twilio-swagger/apis/verify-untagged/

And this is the same spec with tags added:

https://johnchaffee.wiki/twilio-swagger/apis/verify/

As you can see, the tagged version is easier for a human to navigate.

Steps to Reproduce

For each method (get, post, put, delete) add a tags item that describes the resource it is associated with.

For example, add "tags": ["Verifications"] to the post method in the /v2/Services/{ServiceSid}/Verifications path:

      "post": {
        "tags": ["Verifications"],
        "description": "Create a new Verification using a Service",

Technical details:

• twilio-oai version: 1.3.4

Other

Let me know if I can help in any way.

Date fields do not contain date values, instead "string"

Issue Summary

Wrongly typed data for dates. Dummy dates are returned with the string literal "string" as the value which blows up in the json parser.

Steps to Reproduce

1. Using the Twilio c# rest client library, perform an AccountResource.Create action

Code Snippet

            
var account = AccountResource.Create(
                friendlyName: $"SMS Provider Account (orgId: {organizationId})",
                client: client
           );

//The mock server responds with incorrect data for all date fields:
//{\"auth_token\":\"string\",\"date_created\":\"string\",\"date_updated\":\"string\",\"friendly_name\":\"string\",\"owner_account_sid\":\"stringstringstringstringstringstri\",\"sid\":\"stringstringstringstringstringstri\",\"status\":\"active\",\"subresource_uris\":{},\"type\":\"Trial\",\"uri\":\"string\"}"

  // from the Twilio rest client library, the json parsing throws type errors for dates (below)
    public static AccountResource Create(CreateAccountOptions options, ITwilioRestClient client = null)
    {
      client = client ?? TwilioClient.GetRestClient();
      return AccountResource.FromJson(client.Request(AccountResource.BuildCreateRequest(options, client)).Content);
    }

Exception/Log

Twilio.Exceptions.ApiException
Could not convert string to DateTime: string. Path 'date_created', line 1, position 46.
   at Twilio.Rest.Api.V2010.AccountResource.FromJson(String json)
   at Twilio.Rest.Api.V2010.AccountResource.Create(CreateAccountOptions options, ITwilioRestClient client)
   at Twilio.Rest.Api.V2010.AccountResource.Create(String friendlyName, ITwilioRestClient client)
   at TotalExpert.Comms.Sms.TwilioManagement.SubaccountCreator.CreateSubaccount(LegacyId organizationId) in /Users/kevin.boedigheimer/totalexpert/sms-service/CommandProcessor/TwilioManagement/SubaccountCreator.cs:line 28

Newtonsoft.Json.JsonReaderException
Could not convert string to DateTime: string. Path 'date_created', line 1, position 46.
   at Newtonsoft.Json.JsonReader.ReadDateTimeString(String s)
   at Newtonsoft.Json.JsonTextReader.FinishReadQuotedStringValue(ReadType readType)
   at Newtonsoft.Json.JsonTextReader.ReadStringValue(ReadType readType)
   at Newtonsoft.Json.JsonTextReader.ReadAsDateTime()
   at Newtonsoft.Json.JsonReader.ReadForType(JsonContract contract, Boolean hasConverter)
   at Newtonsoft.Json.Serialization.JsonSerializerInternalReader.PopulateObject(Object newObject, JsonReader reader, JsonObjectContract contract, JsonProperty member, String id)
   at Newtonsoft.Json.Serialization.JsonSerializerInternalReader.CreateObject(JsonReader reader, Type objectType, JsonContract contract, JsonProperty member, JsonContainerContract containerContract, JsonProperty containerMember, Object existingValue)
   at Newtonsoft.Json.Serialization.JsonSerializerInternalReader.CreateValueInternal(JsonReader reader, Type objectType, JsonContract contract, JsonProperty member, JsonContainerContract containerContract, JsonProperty containerMember, Object existingValue)
   at Newtonsoft.Json.Serialization.JsonSerializerInternalReader.Deserialize(JsonReader reader, Type objectType, Boolean checkAdditionalContent)
   at Newtonsoft.Json.JsonSerializer.DeserializeInternal(JsonReader reader, Type objectType)
   at Newtonsoft.Json.JsonSerializer.Deserialize(JsonReader reader, Type objectType)
   at Newtonsoft.Json.JsonConvert.DeserializeObject(String value, Type type, JsonSerializerSettings settings)
   at Newtonsoft.Json.JsonConvert.DeserializeObject[T](String value, JsonSerializerSettings settings)
   at Newtonsoft.Json.JsonConvert.DeserializeObject[T](String value)
   at Twilio.Rest.Api.V2010.AccountResource.FromJson(String json)

Technical details:

• twilio-oai version: twilio_api_v2010
• c# client library version: 6.2.2

Field media_external_location in composition object is missing

Issue Summary

Field media_external_location is part of the object v1/Compositions. It is not documented, but present and required when using S3 as a storage media.

Steps to Reproduce

Schema issues, no need steps to reproduce.

Code Snippet

{
    "status": "completed",
    "trim": false,
    "video_layout": {},
    "date_completed": "2021-11-15T12:23:27Z",
    "format": "mp4",
    "url": "https://video.twilio.com/v1/Compositions/CJXxxxxxxxxx",
    "bitrate": 107,
    "media_external_location": "https://buckets3.amazonaws.com/compositions/CJXxxxxxxxxx.mp4",
    "date_deleted": null,
    "account_sid": "ACYYYYYY",
    "duration": 11,
    "audio_sources": [
        "*"
    ],
    "sid": "CJxxxxxx",
    "room_sid": "RMyyyyyy",
    "date_created": "2021-11-15T12:20:21Z",
    "size": 144106,
    "resolution": "640x480",
    "audio_sources_excluded": [],
    "links": {
        "media": "https://video.twilio.com/v1/Compositions/CJ2XXXXXXX/Media"
    }
}

Exception/Log

# paste exception/log here

Technical details:

• twilio-oai version:
• open version:

Test Issue

Test Issue

twilio-oai tag doesn't exist on SO

Creating such a tag requires at least 1500 whatevers; which I do not have.

My question involves Rust and the OAI if someone on SO would pick it up. I can only ask one question at a time on SO. I have several about the OAI Rust implementation. To be clear, I have it working, so these are questions to see if the Rust implementation needs better documentation or improvements in the generated code.

https://stackoverflow.com/questions/71907349/twilio-openapi-implementation-when-using-more-than-one-api

According to
https://stackoverflow.com/questions/tagged/twilio-oai+or+twilio+open

the search is for the tag [twilio-oai]. I was trying to get attention on that tag when I came across the inability to add the tag.

AvailablePhoneNumbers API missing

Any plans to create the AvailablePhoneNumbers API spec on here?

e.g.

https://api.twilio.com/2010-04-01/Accounts/{AccountSid}/AvailablePhoneNumbers/{CountryCode}/Local.json

Open API Verify spec for CreateVerificationCheck has incorrect response code.

Issue Summary

The response code for the CreateVerificationCheck should be a 200 but in the open API spec it has it listed as a 201, which does not match how the API calls respond,

Steps to Reproduce

Go to the open API spec and observe line 9079

https://github.com/twilio/twilio-oai/blob/df28b6ca4a6a77e46d7bb38b88b1ea7af3474973/spec/json/twilio_verify_v2.json#L9078C9-L9101C21

Code Snippet

"responses": {
          "201": {
            "content": {
              "application/json": {
                "schema": {
                  "$ref": "#/components/schemas/verify.v2.service.verification_check"
                },
                "examples": {
                  "verificationChecks": {
                    "value": {
                      "sid": "VEaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa",
                      "service_sid": "VAaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa",
                      "account_sid": "ACaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa",
                      "to": "[phone]",
                      "channel": "sms",
                      "status": "approved",
                      "valid": true,
                      "amount": null,
                      "payee": null,
                      "sna_attempts_error_codes": [],
                      "date_created": "2015-07-30T20:00:00Z",
                      "date_updated": "2015-07-30T20:00:00Z"
                    }
                  },

Exception/Log

Technical details:

• twilio-oai version: 2.0.2
• open version: 3.0

Test

Github actions failing when issues are raised

When I raised an issue, I had an email from Github that it started and failed an action

Here is the run: https://github.com/twilio/twilio-oai/actions/runs/764828871

Swagger missing and schema unexpected

Issue Summary

I have requested the swagger file to implament the the Rest API descriptor to consume Twilio API from WebMethods, below is the converation I had:

Hi can we get the Swagger files so we can inplement the API into our WebMethods?

We are trying to do Twilio - Lookups using the URL: https://lookups.twilio.com/v1/PhoneNumbers
but we are trying to invoke this from WebMethods v10.5 and we already had a call with this vendor and they are asking for the Swagger file so we can add it to our WebMEthods.

I see you have this postman: https://www.postman.com/twilio/workspace/twilio-api/api/b92c1864-8ef6-4384-99b4-da2932aa581d/version/b21d72f9-6144-487e-8601-b118b69e9fb9?tab=documentation
But I'm not able to either Generate the collecion or Generate the code.

#Response from support team:
Thanks for reaching out to Twilio support, I'd be happy to help.

You can check the following repository containing OpenAPI documents for Twilio's API.

https://github.com/twilio/twilio-oai

Files can be found in the json/ and yaml/ directories - https://github.com/twilio/twilio-oai/tree/main/spec

Please note that this project is currently in BETA. We expect the spec to be accurate, but it is currently in active development and unsupported. If you've identified a mismatch between Twilio's API behavior and this specification, please open an issue.

Steps to Reproduce

1. Open SoftwareAG Designer
2. In one package/folder create a new Rest api descriptor
3. Select consumer and click next
4. Select the Swagger file and click next - I tried with the JSON and YAML files supppport team provided from link https://github.com/twilio/twilio-oai/tree/main/spec
   

Code Snippet

# paste code here

Exception/Log

# paste exception/log here

Technical details:

• twilio-oai version:
• open version:

When the mock server can support trusthub API

Issue Summary

I was testing the tusthub API but find there no response from the Mock server.

Steps to Reproduce

1. start the mock server as in the doc.
2. try the API call with the steps in Trusthub REST API

The response is empty. If there was a roadmap, when I can use it to test Trusthub REST API.

Illegal character(pipe | ) in two schema names (twilio_api_v2010.yaml)

Schema name contain pipe( | ) character, which is not allowed.

API spec version 1.4.0 - twilio_api_v2010.yaml
line 868 - api.v2010.account.call.call_notification|instance:
line 2289 - api.v2010.account.notification|instance:

 api.v2010.account.call.call_notification|instance:
      properties:
        account_sid:
          maxLength: 34
          minLength: 34 

api.v2010.account.notification|instance:
      properties:
        account_sid:
          maxLength: 34
          minLength: 34

MessagingServiceSid and statusCallback should be nullable to be consistent with twilio npm module

Issue Summary

The OAI specification for twilio API seems to be incorrect, or at least the nodejs implementation of twilio api may have an inconsistency. https://github.com/twilio/twilio-oai/blob/main/spec/yaml/twilio_api_v2010.yaml#L17395 - should be nullable to be consistent with the typings for twilio api. the OAI specification requires messagingServiceSid whereas the api does not. The same goes for statusCallback; it should be nullable to be consistent with twilio api.

Steps to Reproduce

1. install latest version of twilio via npm
2. npm install -g prism-cli
3. run prism mock https://github.com/twilio/twilio-oai/blob/main/spec/yaml/twilio_api_v2010.yaml
4. create a custom http client

Code Snippet

import twilio from 'twilio';

class PrismHttpClient extends RequestClient {
    request<TData>(opts: RequestClient.RequestOptions<TData>): Promise<Response<TData>> {
        opts.uri = opts.uri.replace(/^https:\/\/.*?\.twilio\.com/, 'http://127.0.0.1:4010'); // note: default prism port is 4010, so change if needed
        return super.request(opts);
    }
}

Then...

const opts ={httpClient: new PrismHttpClient()};
const client = smsClient(sid, token, opts);
const response = await client.messages
        .create({
            body: text,
            from,
            to,
            statusCallback: 'http://localhost:9000/status' // any url where twilio should post message status - this should be nullable also but it is not according to the twilio oai
        });

Then run that code.

Exception/Log

[5:49:29 PM] ›     [VALIDATOR] ⚠  warning   Request did not pass the validation rules
[5:49:29 PM] ›     [VALIDATOR] ✖  error     Request body property MessagingServiceSid must NOT have fewer than 34 characters
[5:49:29 PM] ›     [VALIDATOR] ✖  error     Request body property MessagingServiceSid must match pattern "^MG[0-9a-fA-F]{32}$"
[5:49:29 PM] › [HTTP SERVER] post /2010-04-01/Accounts/AC6d4932eed0ae3cf5d9af4f071965be8f/Messages.json ✖  error     Request terminated with error: https://stoplight.io/prism/errors#UNPROCESSABLE_ENTITY: Invalid request

Technical details:

• twilio-oai version: latest
• twilio version: 4.11.1
• open version:

Beta API possible typos

Issue Summary

I saw your post on twitter that you launched a new OpenAPI. It looks amazing. Really well done.

When checking out the various defs, code spell checker noticed some typos (files and lines are in the pictures.

twilio_verify_v2.json

Best of luck and thanks for sharing

Nullable String values not correct in JSON specs?

Issue Summary

When importing the JSON specs into Postman and using them, there are numerous "issue" warnings that appear on various responses. Particularly the "meta" values for "next_page_url" and "previous_page_url", these are the most noticable.

It appears they are defined as a type of "String" rather that the supported array of "null or String": https://stackoverflow.com/questions/48111459/how-to-define-a-property-that-can-be-string-or-null-in-openapi-swagger

Steps to Reproduce

1. Import a JSON spec into Postman
2. Make an API call that includes meta paging properties in the response
3. Look at the top of the Postman request tab and see the "Issues" warning(s)

Exception/Log

The response body property "meta.previous_page_url" must be string

Technical details:

• twilio-oai version: 1.38.1
• open version: 3.1

Do you plan to add an operationId field to your API?

operationId field would help us.

We are trying to automatically generate the application from your API, but now we have a problem with how to name each operation. Automatically generated names based on current information from API specifications don't look good, so we need to update them manually.

This also would ensure the same operation names in different applications based on your API. Because everyone will be able to use your suggested operation names.

http://spec.openapis.org/oas/v3.0.1#operation-object

Failure to generated Dart-DIO client using twilio_conversations_v1.json

Issue Summary

Problem with client library generation when using:
-> twilio_conversations_v1.json

Code Snippet

after running this OAI generation command:
openapi-generator generate -c openapi_cfg.json -g dart-dio -i twilio_conversations_v1.json -o /Users/dgaedcke/dev/twilio/tw_convos

I get this "default_api.dart" file, with 7 invalid (broken) imports:

// AUTO-GENERATED FILE, DO NOT MODIFY!
import 'dart:async';

import 'package:built_value/serializer.dart';
import 'package:dio/dio.dart';
import 'package:built_collection/built_collection.dart';
import 'package:twConvos/src/api_util.dart';

// all of these files below are missing from the generated code
import 'package:twConvos/src/model/configuration_address_enum_auto_creation_type.dart';
import 'package:twConvos/src/model/configuration_address_enum_method.dart';
import 'package:twConvos/src/model/configuration_address_enum_type.dart';
import 'package:twConvos/src/model/conversation_scoped_webhook_enum_method.dart';
import 'package:twConvos/src/model/conversation_scoped_webhook_enum_target.dart';
import 'package:twConvos/src/model/service_conversation_scoped_webhook_enum_method.dart';
import 'package:twConvos/src/model/service_conversation_scoped_webhook_enum_target.dart';

Technical details:

• openapi-generator-cli 6.6.0
  commit : 7f8b853
  built : -999999999-01-01T00:00:00+18:00

Odd parameter naming standards for date fields that support less than or greater than

Issue Summary

Naming used for date parameters seems to be odd. Date parameter that support less than and/or greater than use > or < in parameter names e.g. StartTime< or StartTime>

Steps to Reproduce

N/A

Code Snippet

"/2010-04-01/Accounts/{AccountSid}/Messages.json": {
      "description": "A Message resource represents an inbound or outbound message.",
      "get": {
        "description": "Retrieve a list of messages belonging to the account used to make the request",
        "operationId": "ListMessage",
        "parameters": [
          ......,
          {
            "description": "The date of the messages to show. Specify a date as `YYYY-MM-DD` in GMT to read only messages sent on this date. For example: `2009-07-06`. You can also specify an inequality, such as `DateSent<=YYYY-MM-DD`, to read messages sent on or before midnight on a date, and `DateSent>=YYYY-MM-DD` to read messages sent on or after midnight on a date.",
            "in": "query",
            "name": "DateSent<",
            "schema": {
              "format": "date-time",
              "type": "string"
            }
          },
          {
            "description": "The date of the messages to show. Specify a date as `YYYY-MM-DD` in GMT to read only messages sent on this date. For example: `2009-07-06`. You can also specify an inequality, such as `DateSent<=YYYY-MM-DD`, to read messages sent on or before midnight on a date, and `DateSent>=YYYY-MM-DD` to read messages sent on or after midnight on a date.",
            "in": "query",
            "name": "DateSent>",
            "schema": {
              "format": "date-time",
              "type": "string"
            }
          },

Exception/Log

N/A

Technical details:

• twilio-oai version: twilio_api_v2010 (1.8)
• open version:

Response status code formatting does not comply with the OpenAPI 3.0 specification

Issue Summary

Your API does not comply with the OpenAPI 3.0 specification
Response status code formatting does not comply with the OpenAPI 3.0 specification.
Response code must be enclosed in quotation marks.

Citation from the OpenAPI 3.0 specification
https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.0.md#patterned-fields-1

"Any HTTP status code can be used as the property name, but only one property per code, to describe the expected response for that HTTP status code. A Reference Object can link to a response that is defined in the OpenAPI Object's components/responses section. This field MUST be enclosed in quotation marks (for example, "200") for compatibility between JSON and YAML."

Part of your API specification with the wrong formatting of the response status code.

        201:
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/api.v2010.account'
          description: Created

twilio_api_v2010.yaml Some endpoints and/or parameters are missing descriptions

Issue Summary

https://github.com/twilio/twilio-oai/blob/main/spec/yaml/twilio_api_v2010.yaml

e.g. endpoint on line 18915 and its parameters are missing descriptions

/2010-04-01/Accounts/{AccountSid}/SigningKeys/{Sid}.json:
    delete:
      description: ''
      parameters:
      - description: ''
        in: path
        name: AccountSid
        required: true
        schema:
          maxLength: 34
          minLength: 34
          pattern: ^AC[0-9a-fA-F]{32}$
          type: string
      - description: ''
        in: path
        name: Sid
...

Waddupppp?

Add `Recordings/{Sid}/Media`

Issue Summary

Hi team!
It would be more helpful to have the Recordings/{SId}/Media subresource included.
https://www.twilio.com/docs/video/api/recordings-resource#get-media-by-sid

Technical details:

• twilio-oai version: v1.41.0

TrustHub spec does not include route to BrandRegistrations

Issue Summary

When making a request to BrandRegistrations, the mock server returns no route found. I believe this route needs to be added to the twilio_trusthub_v1.json / yaml file.

Steps to Reproduce

1. Start a mock server: prism mock https://raw.githubusercontent.com/twilio/twilio-oai/main/spec/json/twilio_trusthub_v1.json
2. Create a new Twilio Client with accountSid/token as per normal, pointing to the prism host.
3. Make a request to brand registration:

const brand = await twilioClient.messaging.brandRegistrations.create({
        brandType: 'STARTER',
        customerProfileBundleSid: starterCustomerProfileSid,
        a2PProfileBundleSid: a2pStarterTrustBundleSid,
});

4. Receive error in Prism Server:

prism_1  | [9:15:05 PM] › [HTTP SERVER] post /v1/a2p/BrandRegistrations ✖  error     Request terminated with error: https://stoplight.io/prism/errors#NO_PATH_MATCHED_ERROR: Route not resolved, no path matched

5. Searchtwilio_trusthub_v1.json for any keyword of BrandRegistrations: no matches found.

Code Snippet

See above

Exception/Log

See above

Technical details:

• twilio-oai version: twilio_trusthub_v1.json
• open version:

Missing request body definition for updating the configuration of a Twilio Flex instance

Issue Summary

First of all, great work on the OpenAPI definitions. They're super handy to have when building against the APIs.

When looking at the OpenAPI definition for the Twilio Flex API, I noticed there was no definition/ schema for the request body to describe the request payload which needs to be supplied to update the configuration of a Twilio Flex Instance (OperationId: UpdateConfiguration, path: /v1/configuration, HTTP method: post). This can be seen in the YAML OpenAPI template

I have searched through the Twilio API docs and I found out the request body needs to be JSON, as seen here however the documentation doesn't specify all the properties which can be modified and the data types for each of the properties.

Is it possible to get the request body added to the OpenAPI definitions for UpdateConfiguration?

Steps to Reproduce

N/A

Code Snippet

/v1/Configuration:
  description: Configuration for a Flex instance
  get:
    ...
  post:
    description: ''
    operationId: UpdateConfiguration
    responses:
      '200':
        content:
          application/json:
            schema:
              $ref: '#/components/schemas/flex.v1.configuration'
        description: OK
    security:
    - accountSid_authToken: []
    x-maturity:
    - GA
  ...

Exception/Log

N/A

Technical details:

• twilio-oai version: 1.16.0
• open version:

Test

Test

What does mean question marks(?) at the beginning of two lines? twilio_api_v2010.yaml

Issue Summary

https://github.com/twilio/twilio-oai/blob/main/spec/yaml/twilio_api_v2010.yaml
There are question marks at the beginning of these two lines -
line 1472
line 13284
There is also colon ( : ) at the beginning of the next line.
It's a bug or feature?

      type: object
    ? api.v2010.account.incoming_phone_number.incoming_phone_number_assigned_add_on.incoming_phone_number_assigned_add_on_extension
    : properties:
        account_sid:

     x-path-type: list
  ? /2010-04-01/Accounts/{AccountSid}/IncomingPhoneNumbers/{ResourceSid}/AssignedAddOns/{AssignedAddOnSid}/Extensions/{Sid}.json
  : description: 'TODO: Resource-level docs'
    get:
      description: Fetch an instance of an Extension for the Assigned Add-on.
      parameters:

Don't plan to add a parameter to sort the results?

In the actual state we can't change sorting direction and the list result is sorted from the newest to the oldest.

We have several scenarios where it is better for us to sort from the oldest.

Test issue

Test issue

CreateMessage API Request Body Required Fields

Issue Summary

In the file and operationID:
File: https://github.com/twilio/twilio-oai/blob/main/spec/json/twilio_api_v2010.json
OperationID: CreateMessage

The required fields in the Request Body according to the open API spec is only: "To"
However, when using the API, the following fields are also needed:
"From"
"Body"

Is this done intentionally in the open API spec?

Code Snippet

"required": [ "To" ]