En busca de la validación: validación de datos en Python con Pydantic y Vonage Verify

Esta entrada del blog ofrece una introducción a Pydantic, la popular biblioteca de validación de datos para Python. Incluye una demostración de las ventajas que ofrece Pydantic al utilizar la Verify API de Vonage. 

Introducción

¿Qué es el «duck-typing» en Python?

Para entender por qué Pydantic es una biblioteca tan útil, es importante comprender primero cómo funciona el tipado en Python. En programación, el «tipado» se refiere a los sistemas de clasificación y categorización de datos. El tipo de los datos determina cómo se puede actuar sobre ellos; por ejemplo, no se puede sumar la palabra «dos» con el número 2.

Python debe gran parte de su éxito y popularidad a su flexibilidad en cuanto a los tipos de datos. A diferencia de la mayoría de los lenguajes compilados, que exigen declarar los tipos de forma explícita, Python implementa lo que se conoce como «duck-typing». El «duck-typing» es un sistema de tipos dinámico que parte de la base de que, si un objeto «camina como un pato y grazna como un pato, entonces debe de ser un pato».

Más concretamente, según la documentación de Python, el «duck-typing» es:

«Un estilo de programación que no tiene en cuenta el tipo de un objeto para determinar si tiene la interfaz adecuada; en su lugar, simplemente se invoca o se utiliza el método o el atributo… Al dar prioridad a las interfaces en lugar de a los tipos específicos, un código bien diseñado mejora su flexibilidad al permitir la sustitución polimórfica. El «duck-typing» evita las comprobaciones que utilizan type() o isinstance()».

En la práctica, un ejemplo de ello es la función len función de Python. len() devuelve «la longitud (el número de elementos) de un objeto». En el código que aparece a continuación, fíjate en cómo len() se genera correctamente un resultado independientemente del tipo de objeto con el que se llame:

>>> example_1 = "Hello? World!"
>>> type(example_1)
<class 'str'>

>>> example_2 = [1, 3, 5, 8]
>>> type(example_2)
<class 'list'>

>>> example_3 = {"hello" : "world", "foo": "bar"}
>>> type(example_3)
<class 'dict'>

>>> len(example_1)
13                                 # 13 letters in "Hello? World!"

>>> len(example_2)
4                                  # 4 items in the list

>>> len(example_3)
2                                  # 2 key-value pairs in the dictionary

En un ejemplo de tipado dinámico que probablemente se acerque más a lo que se suele ver en Python en la práctica, el código siguiente define tres clases diferentes de razas de perros, cada una de las cuales puede bark():

class Pug:
    def bark(self):
        print("The pug goes arf arf!")

class LabradorRetriever:
    def bark(self):
        print("The labrador retriever goes arf arf!")

class Wolfhound:
    def bark(self):
        print("The wolfhound goes arf arf!")

Puedes crear una instancia de cada raza de perro y llamar bark() en cada una de ellas sin que se produzca ningún error, ya que todas poseen la misma interfaz. Gracias al «duck-typing», el siguiente código se ejecuta correctamente:

>>> pets = [Pug(), LabradorRetriever(), Wolfhound()]

>>> for pet in pets:
...     pet.bark()

The pug goes arf arf!
The labrador retriever goes arf arf!
The wolfhound goes arf arf!

pet puede ser de clase Pug, LabradorRetriever, o Wolfhound y Python seguirá llamando a la bark función sin que se produzca ningún error.

 Esto puede resultar práctico y, en muchos contextos, es precisamente lo que se busca. Para la creación de scripts, la ciencia de datos y el trabajo exploratorio, el tipado dinámico de Python es una ventaja, no un inconveniente. El «duck typing» te permite iterar rápidamente sin la carga que suponen las declaraciones de tipos rígidas. Esta es una de las principales razones por las que Python se ha convertido en el lenguaje dominante para los flujos de trabajo de IA y ciencia de datos.

Sin embargo, la situación cambia significativamente en el código backend de producción. Una aplicación de Flask o Django sin tipos declarados puede generar dificultades a la hora del mantenimiento y la depuración. Con el «duck-typing» de Python, las discrepancias de tipos se manifiestan como errores crípticos en tiempo de ejecución, en lugar de como fallos claros y detectables desde el principio. El problema se agrava aún más cuando las aplicaciones dependen de tipos específicos de datos para funcionar según lo previsto, como al trabajar con API, procesar archivos de configuración o gestionar las entradas de los usuarios. 

Por ejemplo, si has definido la siguiente clase:

class Sphynx:
    def meow(self):
        print("The sphynx goes meow meow!")

Y luego actualicé el código de ejemplo para incluir una instancia de Sphynx en la lista de pets por la que iterar, te encontrarás con un error:

>>> pets = [Pug(), LabradorRetriever(), Sphynx()]

>>> for pet in pets:
...     pet.bark()
...     

The pug goes arf arf!
The labrador retriever goes arf arf!
Traceback (most recent call last):
  File "<python-input-74>", line 2, in <module>
    pet.bark()
    ^^^^^^^^
AttributeError: 'Sphynx' object has no attribute 'bark'

Como ilustra este ejemplo, en determinados contextos, la flexibilidad del «duck-typing» se convierte en un inconveniente. Por ejemplo, es posible que un tipo incorrecto pasado a una llamada a la API no genere un error hasta que la solicitud ya esté en curso, lo que podría suponer un gasto innecesario en una llamada facturable que estaba destinada a fallar desde el principio.

Una forma de abordar algunos de los problemas que surgen con el tipado dinámico es mediante las indicadores de tipo.

¿Qué son las anotaciones de tipo?

Una indicación de tipo es una anotación de código que «especifica el tipo esperado para una variable, un atributo de clase, un parámetro de función o un valor de retorno». Por lo tanto, una anotación de tipo se refiere a cómo se utilizan sintácticamente las indicaciones de tipo en Python.

El siguiente código es un ejemplo básico del uso de las anotaciones de tipo:

def greeting(name: str) -> str:
    return 'Hello ' + name

En este ejemplo, la indicación de tipo es str y la anotación de tipo es la name: str y -> str . La anotación de tipo nos indica que el tipo esperado del parámetro name es una cadena y que el tipo de retorno esperado de la función greeting es una cadena.

Si añadimos anotaciones de tipo a la clase de ejemplo Pug podría quedar así:

class Pug:
    def init(self, name: str) -> None:
        self.name: str = name

    def bark(self) -> None:
        print(f"The pug {self.name} goes arf arf!")

Y si actualizamos nuestro pets código de iteración para incluir la anotación de tipo, quedaría así:

def make_dogs_bark(pets: List[Pug | LabradorRetriever | Wolfhound ]) -> None:
    for pet in pets:
        pet.bark() 

make_dogs_bark([Pug(), LabradorRetriever(), Sphynx()])

Como su nombre indica, se trata simplemente de sugerencias. Ayudan a que el código sea más legible y fácil de mantener, pero el intérprete de Python no las impone. Podríamos utilizar una herramienta adicional como mypy para comprobar los tipos y recibir un error como este:

error: List item 2 has incompatible type "Sphynx"; expected "Pug | LabradorRetriever | Wolfhound"  [list-item]

Esto tendría que realizarse como un paso adicional; no hay nada que impida que este código se ejecute y genere un error en tiempo de ejecución.

En busca de reconocimiento

Para evitar errores en tiempo de ejecución —como una llamada a la API con datos incorrectos—, podrías validar los datos de tu solicitud antes de enviarla. En el código de ejemplo, podríamos definir algún tipo de validación para asegurarnos de que cada elemento de la lista pets pueda bark():

def make_dogs_bark_safely(dogs):
    """Manual validation in the function"""
    for dog in dogs:
        if not hasattr(dog, 'bark') or not callable(getattr(dog, 'bark')):
            raise TypeError(f"Invalid dog type: {type(dog).__name__}")
        dog.bark()

# Now this fails immediately with a clear message:
pets = [Pug(), Sphynx()]

make_dogs_bark_safely(pets)
# TypeError: Invalid dog type: Sphynx

Además de volverse rápidamente tedioso y poco manejable, este patrón socava algunas de las ventajas del tipado dinámico inherente a Python, al tiempo que no aprovecha algunas de las ventajas de la anotación de tipos.

Afortunadamente, Pydantic ofrece validación de datos sin renunciar a la facilidad y rapidez del lenguaje, gracias a una sintaxis ya integrada.

¿Qué es Pydantic?

Pydantic es una biblioteca de validación de datos para Python que ofrece las siguientes ventajas:

• Aprovecha las sugerencias de tipo para controlar la validación del esquema y la serialización.

• Usos Utiliza Rust en segundo plano para su lógica de validación principal, lo que se traduce en un impacto mínimo en el rendimiento.

• Admite la validación de muchos tipos de la biblioteca estándar , entre los que se incluyen dataclass y TypedDict.

• Funciona tanto en modo estricto o flexible al gestionar los tipos.

• Puede generar esquemas JSON de forma predeterminada, lo que permite una integración perfecta con otras herramientas.

• Genera automáticamente documentación a partir de los modelos.

Analicemos con más detalle cómo se combinan estas características en la práctica para ofrecer una validación de datos fiable y eficiente, en consonancia con la sintaxis y la estructura de Python.

Funciones principales de validación de Pydantic

Es importante comprender que, en Pydantic, «validación» se refiere a «el proceso de instanciar un modelo (u otro tipo) que se ajuste a los tipos y restricciones especificados». En otras palabras, la validación de Pydantic se aplica al resultado de la instanciación de un modelo, no a los datos de entrada. Por ello, Pydantic genera un ValidationError cuando los datos no pueden analizarse correctamente para convertirlos en una instancia de un modelo.

Modelo base

BaseModel es el núcleo de Pydantic. Se hereda de él para definir modelos de datos con campos anotados con tipos. Uno de los principales métodos para definir esquemas en Pydantic es a través de los modelos. Al instanciar un BaseModel Pydantic valida automáticamente los datos según el esquema definido.

Al utilizar Pydantic, la Pug clase tiene ahora este aspecto:

class Pug(BaseModel):
    name: str
    age: int
    color: str = "fawn"

    def bark(self):
        print(f"The pug {self.name} goes arf arf!")

Si crearas una instancia de Pug, Pydantic se aseguraría de que el objeto resultante fuera name de tipo cadena, un age de tipo entero y un color de tipo cadena con fawn como valor por defecto.

Sugerencias de tipo y campos obligatorios

Las anotaciones de tipo controlan la validación del esquema y la serialización. Los campos declarados únicamente con una anotación de tipo son obligatorios; los campos con valores por defecto son opcionales.

Por Pug ejemplo, el name campo está anotado con str lo que significa que cualquier cadena servirá, pero una cadena debe proporcionarse; lo mismo se aplica al age campo. El color campo, sin embargo, proporciona un valor por defecto de fawn y, por lo tanto, no es obligatorio al instanciar un Pug.

Coerción de tipos

Pydantic se puede utilizar tanto en modo estricto como en modo flexible (por defecto). En modo flexible, la biblioteca convertirá automáticamente los datos al tipo definido en el esquema.

Así, por ejemplo, si pasáramos "5" como cadena para el age de un Pug, Pydantic la convertiría en un entero.

Configuración de campo

La Field función permite añadir metadatos y restricciones a los campos del esquema.

Algunos parámetros que se utilizan habitualmente son:

• Restricciones como «mayor que» gt) y mayor o igual que ge), y min_length y max_length

•  Alias para asignar los nombres de los campos de entrada y salida mediante alias, validation_alias, y serialization_alias)

• Modo estricto para evitar la conversión de tipos en determinados campos strict=True)

Para aplicar restricciones al name campo de Pug, se utilizaría el siguiente código:

class Pug(BaseModel):
    name: str = Field(..., min_length=1, description="The pug's name")
    age: int
    color: str = "fawn"

    def bark(self):
        print(f"The pug {self.name} goes arf arf!")

Serialización

Las instancias de modelos de Pydantic se pueden convertir en diccionarios sin necesidad de escribir código de serialización adicional, utilizando model_dump(). Esto facilita la serialización a JSON u otros formatos para su uso en otras partes del proyecto. Por ejemplo, model_dump_json() serializa un modelo directamente a JSON.

A continuación se muestra un ejemplo de cómo crear una instancia de Pug y, a continuación, serializarla utilizando una de las funciones integradas de Pydantic:

matty_pug = Pug(name="Matty", age=14)

result = matty_pug.model_dump()

print(result)

Lo que daría como resultado lo siguiente:

{'name': 'Matty', 'age': 14, 'color': fawn}

¿Cuál es un caso de uso real de Pydantic?

Desde su creación, Pydantic se ha convertido rápidamente en una de las bibliotecas de validación de datos más utilizadas para Python. Aproximadamente 8.000 paquetes de PyPI utilizan Pydantic, entre los que se incluyen (y son los más conocidos) FastAPI, huggingface, Django Ninja, SQLModel, LangChain y Vonage.

En noviembre de 2024, Vonage lanzó una versión completamente reescrita desde cero del SDK de Python de Vonage. No siempre es fácil empezar de cero, pero la reescritura supuso una oportunidad para introducir algunas mejoras estructurales fundamentales y optimizar la interacción del usuario con el SDK.

Entre los cambios incluidos en esta iniciativa se encontraba la incorporación de Pydantic al SDK con el fin de facilitar la llamada a las API de Vonage y el análisis de las respuestas.

Echa un vistazo al Video que aparece a continuación para escuchar a uno de nuestros desarrolladores que trabaja en el SDK de Python y ver qué opina sobre el uso de Pydantic.

Cómo utiliza el SDK de Python de Vonage los modelos de Pydantic

El uso de modelos Pydantic para crear solicitudes garantiza la tipificación correcta y facilita el envío de los objetos adecuados a las API de Vonage. Con la versión 4 del SDK, las respuestas de las API ahora se deserializan en modelos Pydantic totalmente documentados, lo que proporciona mayor coherencia que la devolución de diccionarios, como ocurría en la versión anterior. Además, sigue siendo posible convertir los modelos Pydantic en diccionarios o cadenas JSON con model.model_dump y model.model_dump_json respectivamente.

En esta demostración, analizaremos la Verify API de Vonage y cómo se modela mediante Pydantic en el SDK.

¿Qué es Verify API de Vonage?

La Verify API es el producto de autenticación de dos factores (2FA) de última generación de Vonage. Con la Verify API, puedes autenticar a tus usuarios y prevenir el fraude gracias a una API sencilla y fácil de usar que elimina la complejidad de la autenticación de dos factores a escala global.

Amplía los métodos de autenticación tradicionales al admitir una gama más amplia de canales, incluidos los canales «over-the-top» (OTT) como WhatsApp, así como SMS, voz y correo electrónico. La API admite tanto tokens web JSON (JWT) como autenticación básica. La autenticación básica es más fácil de poner en marcha, pero no admite funciones avanzadas como las listas de control de acceso (ACL). Puedes utilizar la autenticación JWT o la básica, pero no ambas a la vez. Puedes obtener más información sobre la autenticación en la documentación.

A grandes rasgos, la Verify API sigue este flujo de trabajo:

1. Un usuario final inicia una solicitud de autenticación de dos factores en una aplicación

2. En el backend, esta solicitud de autenticación de dos factores (2FA) da lugar a una solicitud a la Verify API

3. La Verify API envía una contraseña de un solo uso (OTP) al usuario final a través del canal configurado (SMS, llamada de voz, WhatsApp o correo electrónico).

4. El usuario final introduce la contraseña de un solo uso (OTP) en la aplicación

5. Esto inicia una solicitud de Verify para comparar la contraseña de un solo uso (OTP) facilitada por el usuario final con la OTP generada por la API.

6. El resultado de esa comprobación determina entonces lo que ocurre a continuación (se autentica al usuario final, etc.)

A diagram of the Verify V2 Request with Summary Callbacks.Una solicitud típica de verificación inicial incluye la siguiente carga útil:

{

   "locale": "es-es",
   "channel_timeout": 180,
   "client_ref": "myPersonalRef",
   "code_length": 4,
   "code": "e4dR1Qz",
   "brand": "ACME",
   "template_id": "4ed3027d-8762-44a0-aa3f-c393717413a4",
   "workflow": [
      {
         "channel": "sms",
         "to": "44770090000"
      },
      {
         "channel": "voice",
         "to": "44770090000"
      }
   ]
}

Esto se explica con más detalle a continuación:

Para obtener más información sobre la API y su funcionamiento, consulta la documentación de Vonage Verify.

Una solicitud realizada con éxito devuelve un 202 OK para indicar que se ha iniciado la solicitud de verificación. La respuesta también incluirá un request_id que es necesario para completar el proceso de verificación:

{"request_id": "c11236f4-00bf-4b89-84ba-88b25df97315",}

Al mismo tiempo, Vonage envía una contraseña de un solo uso (OTP) al usuario final a través del flujo de trabajo configurado, probando cada canal en el orden en que están definidos.

Una vez que el usuario final recibe e introduce la contraseña de un solo uso (OTP) en la aplicación, se envía otra solicitud al punto final «Verify» con el request_id como parámetro de ruta https://api.nexmo.com/v2/verify/:request_id) y la OTP en el cuerpo de la solicitud para la code clave.

Si el código facilitado coincide con el código generado y enviado por Vonage, se 200 OK se devuelve una respuesta junto con un "status": "complete" .

Demostración: ¿Cómo utiliza la Verify API a Pydantic?

El SDK de Python de Vonage facilita la implementación de las API de Vonage en una aplicación de Python. La incorporación de Pydantic al SDK hace que el uso de las API resulte aún más sencillo. Con Pydantic, en lugar de detectar un error después de realizar una llamada a la API e incurrir en gastos, los modelos de solicitud se validan antes la ejecución, sin necesidad de código adicional para ello.

La demostración de esta entrada del blog es una aplicación mínima de autenticación de dos factores (2FA) que utiliza el marco FastAPI. El usuario final accede a una página web en la que introduce su dirección de correo electrónico. A continuación, mediante la Verify API, la aplicación genera un código OTP que se envía a la dirección de correo electrónico facilitada por el usuario final. El usuario final introduce ese código en la aplicación y, si la verificación de Verify se realiza con éxito, se le recompensa con un GIF animado. 

Si quieres, puedes ir directamente al el código y utilizar el archivo README para ponerlo en marcha.

El siguiente código es donde se crea la solicitud «Verify»:

   verify_request = VerifyRequest(
        brand=settings.verify_brand_name,
        workflow=[
            EmailChannel(to=email),
        ],
        channel_timeout=60,
        code_length=5,
    )

Si nos adentramos en el VerifyRequest objeto, nos encontramos con un modelo Pydantic:

class VerifyRequest(BaseModel):
    brand: str = Field(..., min_length=1, max_length=16)
    workflow: list[
        Union[
            SilentAuthChannel,
            SmsChannel,
            WhatsappChannel,
            VoiceChannel,
            EmailChannel,
        ]
    ]
    locale: Optional[Locale] = None
    channel_timeout: Optional[int] = Field(None, ge=15, le=900)
    client_ref: Optional[str] = Field(None, min_length=1, max_length=16)
    code_length: Optional[int] = Field(None, ge=4, le=10)
    code: Optional[str] = Field(None, pattern=r'^[a-zA-Z0-9]{4,10}$')

    @model_validator(mode='after')
    def check_silent_auth_first_if_present(self):
        if len(self.workflow) > 1:
            for i in range(1, len(self.workflow)):
                if isinstance(self.workflow[i], SilentAuthChannel):
                    raise VerifyError(
                        'If using Silent Authentication, it must be the first channel in the "workflow" list.'
                    )
        return self

El esquema traduce la solicitud de la API en tipos mediante anotaciones de Python y la Field función para definir restricciones. El workflow campo define un Union tipo derivado de otros tipos modelados, lo que demuestra cómo se pueden anidar los tipos.

Por último, el model_validator(mode='after') es un decorador de Pydantic que ofrece configuración adicional sobre cómo VerifyRequest se debe validar el modelo. En este caso, el def check_silent_auth_first_if_present método se ejecuta después de la VerifyRequest modelo, para garantizar que, si SilentAuthChannel se incluya en el flujo de trabajo, debe aparecer en primer lugar.

Verificación por correo electrónico

Tras generar y activar un entorno virtual, e instalar las dependencias necesarias según el archivo README, puedes ejecutar la aplicación de demostración con lo siguiente:

fastapi dev

Esto iniciará una aplicación web en http://127.0.0.1:8000:

A screenshot of the index page inviting the end-user to enter their email address to try out the Vonage Verify API.Al hacer clic en «Enviar código de verificación» se activa el flujo de trabajo de la Verify API. Se te redirigirá a una página web en la que podrás introducir el código enviado a la dirección de correo electrónico que has facilitado:

A screenshot of the verification page inviting the end-user to enter the code they received in their email.Si introduces aquí el código correcto, se te redirigirá a una página de confirmación.

En el fondo, el código utiliza los modelos Pydantic del SDK para garantizar que la solicitud de Verify se forme y se gestione correctamente.

Verificación sin validación: pruebas sin Pydantic

Ahora veamos cómo Pydantic facilita el uso de la Verify API.

En el siguiente código, tenemos dos funciones que realizan la misma tarea: enviar una solicitud al /verify punto final. Una de las funciones crea el cuerpo de la solicitud manualmente y la otra utiliza Pydantic.

Utilizando un cuerpo de solicitud creado manualmente:

def without_pydantic(request_payload):

    jwt_client = JwtClient(
        application_id=settings.vonage_application_id,
        private_key=settings.vonage_private_key_path,
    )

    jwt_token = jwt_client.generate_application_jwt()

    payload = {
        "brand": request_payload["brand"],
        "workflow": [
            {
                "channel": "email",
                "to": request_payload["to_email"],
            }
        ],
        "channel_timeout": request_payload["channel_timeout"],
        "code_length": request_payload["code_length"],
    }

    response = requests.post(
        "https://api.nexmo.com/v2/verify",
        headers={
            "Authorization": f"Bearer {jwt_token.decode()}",
            "Content-Type": "application/json",
        },
        json=payload,
    )

    return response

Uso de Pydantic:

def with_pydantic(request_payload):

    client = Vonage(
        Auth(
            application_id=settings.vonage_application_id,
            private_key=settings.vonage_private_key_path,
        )
    )

    verify_request = VerifyRequest(
        brand=request_payload["brand"],
        workflow=[EmailChannel(to=request_payload["to_email"])],
        channel_timeout=request_payload["channel_timeout"],
        code_length=request_payload["code_length"],
    )

    client.verify.start_verification(verify_request)

    last_response = client.http_client.last_response

    return last_response

A continuación, el código utiliza unittest para probar las funciones con test_data que incumplan los parámetros de la API:

   test_data = {
        "brand": 12345,
        "to_email": 678910,
        "channel_timeout": "sixty",
        "code_length": "five",
    }

Ejecuta las pruebas con el siguiente comando:

python -m unittest -v

Al ejecutar las pruebas deberían producirse dos resultados diferentes: un error y un fallo.

La prueba de la función que utiliza Pydantic debería devolver este error:

pydantic_core._pydantic_core.ValidationError: 1 validation error for EmailChannel
to
  Input should be a valid string [type=string_type, input_value=678910, input_type=int]
    For further information visit https://errors.pydantic.dev/2.13/v/string_type

Lo que hay que destacar aquí es que la prueba no falló , sino que se produjo un error porque Pydantic detectó un tipo de datos incorrecto antes de de que se realizara la solicitud. Además, el propio mensaje de error proporciona información útil para la depuración, en lugar de un mensaje genérico de error de tipo. No solo sabemos que el tipo de datos proporcionado no cumplía los requisitos del modelo, sino que también sabemos cuál es el tipo esperado, así como el tipo que se pasó:

Input should be a valid string [type=string_type, input_value=678910, input_type=int]

La prueba para la función sin Pydantic devuelve un error:

AssertionError: 422 != 202 : Test without Pydantic failed with: 422. Expected: 202

Esto significa que se realizó la solicitud y, tal y como la API está definida, devolvió un 422 por parámetros no válidos. 

En este escenario de prueba limitado, una llamada a la API errónea es insignificante; sin embargo, a mayor escala, puede suponer un error muy costoso. El uso de Pydantic para validar un modelo de solicitud antes de realizar la llamada a la API ayuda a minimizar las llamadas innecesarias, permite gestionar los errores de forma más fluida y facilita el trabajo de los desarrolladores.

En resumen

Pydantic ofrece una solución potente y de alto rendimiento para la validación de datos en Python, lo que ayuda a los desarrolladores a evitar los posibles inconvenientes del «duck-typing». Al definir esquemas, restricciones y reglas de validación con los modelos de Pydantic, puedes garantizar la integridad de los datos y detectar errores antes incluso de que se envíen las solicitudes a la API. Esto te evita costosas llamadas a la API no válidas y hace que la gestión de errores sea más fluida.

Tal y como se ha demostrado con la integración del SDK de Python de Vonage con la Verify API, Pydantic facilita el trabajo con modelos de solicitud complejos y anidados, al tiempo que mantiene la legibilidad y la facilidad de mantenimiento del código. Con la versión 4 del SDK, las respuestas de la API se deserializan en modelos Pydantic totalmente documentados, lo que te ofrece mayor coherencia, mejor compatibilidad con las herramientas y, en general, una experiencia de desarrollo más limpia.

Lecturas recomendadas y referencias

• Actualizaciones de autenticación silenciosa en Verify API: Las nuevas actualizaciones de la autenticación silenciosa en la Verify API mejoran la experiencia de desarrollo y pruebas.

• Crea un inicio de sesión en vídeo sin contraseña con Silent Auth y la Video API: Utiliza Silent Auth con Vonage Video para verificar a los usuarios automáticamente e iniciar sesiones en tiempo real más rápidamente, sin necesidad de contraseñas ni códigos.

• Presentamos la verificación «Zero-Tap» para WhatsApp: Anunciamos la disponibilidad de la verificación «Zero-Tap» para WhatsApp a través de la API Vonage Verify v2.