Preguntas frecuentes de Lookup API

Lookup responde preguntas sobre un destinatario antes de que le envíe. Proporcione un número de teléfono y le dice qué es ese número: la red que lo sirve, el país, si ha cambiado de red y qué tipo de línea es. Proporcione una dirección de correo electrónico y le dice si vale la pena enviar a esa dirección.

Dos cosas, una operación cada una. Una consulta de número de teléfono devuelve el país, la red que sirve al número, la red que lo emitió, si ha cambiado entre ambas y el tipo de línea, además de cualquier propiedad que solicite. Una consulta de dirección de correo electrónico devuelve un veredicto, una puntuación de confianza y los indicadores detrás de él.

Cada consulta es una solicitud y una respuesta. No hay nada que crear, nada que sondear y nada que limpiar después. Los métodos tipados se incluyen en los SDK de Go, TypeScript, Python y PHP, y bird lookup phone-number y bird lookup email hacen lo mismo desde la CLI.

Sí. La página de Lookup en el panel ejecuta las mismas dos operaciones de una en una, y es la forma más rápida de ver cómo luce una respuesta antes de construir sobre ella.

Una clave API con el alcance lookup y un wallet de organización que pueda cubrir el cargo. El precio es por consulta sin tarifa por usuario, así que no hay plan que elegir primero.

Úselo cuando quiera decidir antes de comprometerse: filtrar un registro, evaluar un lead antes de actuar sobre él, o enrutar un mensaje de forma diferente según el tipo de línea. Obtiene una respuesta sobre la que puede actuar sin enviar nada primero.

Por consulta. Cada consulta se cobra al monedero de su organización. Una consulta de número de teléfono cobra una vez por la consulta base, más un cargo por cada propiedad que se devuelva con respuesta. Una consulta de dirección de correo electrónico cobra una vez por cada dirección respondida. No hay tarifa por usuario.

La página de precios de Lookup muestra la tarifa de la consulta base, de cada propiedad y de una consulta de dirección de correo electrónico. Las tarifas varían según la propiedad, porque cada una proviene de una fuente de datos diferente.

No. Una propiedad se cobra solo cuando se entrega. Una que no pudo responderse se devuelve con un estado indicándolo y no tiene costo, y la consulta base se sigue sirviendo junto a ella.

No se cobra nada. Un número mal formado, una dirección que rechazamos y una fuente de datos inalcanzable no tienen costo.

Sí. Cada dirección respondida se cobra, incluidas las no entregables. Esa es la respuesta que solicitó, y es la que le ahorra un rebote.

No si envía un Idempotency-Key. Una repetición de la misma solicitud reproduce la respuesta almacenada en lugar de ejecutar una nueva consulta. Los formularios GET, que colocan el número o la dirección en la URL, no pueden llevar una clave de idempotencia, así que use POST para todo lo automatizado.

El límite de velocidad de consulta comienza en 10 solicitudes por minuto, contadas por credencial activa, de modo que una clave ocupada no puede dejar sin recursos a otra. Cada consulta accede a una fuente de datos externa y cobra a su wallet por la respuesta, por eso comienza donde comienzan los límites de envío.

Hoy no. Ninguna de las dos operaciones tiene formato por lotes, así que verificar una lista completa no es para lo que está dimensionado. Pídanos que aumentemos el límite si eso es lo que necesita, en lugar de buscar soluciones alternativas.

El alcance lookup a nivel de escritura. No tiene nivel de lectura: todos los endpoints de consulta requieren escritura, incluida la obtención de un resultado por el que ya pagó. Los propietarios y administradores lo tienen por defecto, los miembros no.

Cuatro que importan. E22000 cuando el número no es válido en formato internacional, E22003 cuando la dirección no es una dirección de correo electrónico válida, E22001 cuando el wallet de la organización no puede cubrir la consulta, y E22002 cuando Lookup no está disponible temporalmente. Ninguno de ellos le genera un cargo.

No. Una propiedad que falla regresa como un estado en su propio bloque, con la consulta base servida junto a ella. Solo si la consulta base falla, la solicitud falla, y entonces falla por completo en lugar de devolver una respuesta medio vacía que tendría que inspeccionar para descubrir que estaba vacía.

La consulta base responde el país del número, la red que lo sirve actualmente, la red que emitió su rango, si alguna vez cambió de red y un tipo de línea general. Siempre se ejecuta, y si no puede responderse, toda la solicitud falla en lugar de devolver una respuesta a medias.

Primero el código de llamada del país, luego el número nacional. El signo más inicial es opcional y 00 funciona en su lugar, por lo que +31612345678, 31612345678 y 0031612345678 son el mismo número.

Un número escrito para marcar dentro de un país, sin código de país, devuelve E22000 en lugar de intentar adivinarlo. Agregar un código de país a 0612345678 nombraría un número real en otro lugar y se le cobraría por consultar ese número en su lugar.

mobile, fixed_line, voip, toll_free, premium_rate, satellite, pager, payphone, m2m, service, other o unknown. unknown significa que la plataforma del operador no tiene clasificación para el rango, y other significa que tiene una sin equivalente aquí. Solicite la propiedad classification para obtener el servicio asignado con mayor precisión.

network_info es la red que sirve el número actualmente y original_network_info es la red que emitió su rango. Ambas difieren una vez que un número ha sido portado, y flags contiene ported en ese caso. Solicite la propiedad porting cuando también necesite la fecha y el registro completo.

Porque el número no pertenece a un solo país, como ocurre con un rango no geográfico. Los campos sin valor se omiten en lugar de devolverse como null, por lo que cada campo presente en la respuesta fue resuelto.

No. Una consulta nunca contacta al número. Lee datos del operador e inteligencia del número, y las propiedades de presencia y roaming consultan la red en la que el número está registrado, por lo que nada suena y nada llega al dispositivo.

Seis, nombradas en type. classification para el servicio asignado preciso del rango, porting para cuándo el número cambió de red por última vez y cada movimiento registrado, presence para saber si está activo en la red en este momento, roaming para saber si está en itinerancia y en qué red, sim_swap para cuándo se cambió su SIM por última vez, y score para una puntuación de credibilidad de 0 a 100.

Sí. classification, porting y score leen datos almacenados y responden rápidamente. presence, roaming y sim_swap consultan la red en vivo, por lo que son más lentas y su cobertura varía según el operador. Espere unavailable o inconclusive para esas tres con más frecuencia que para las almacenadas.

ok significa que la propiedad fue respondida, su valor está en la respuesta y se cobró. unavailable significa que no llegó respuesta y no se cobró. inconclusive significa que llegó una respuesta pero no resuelve la propiedad, lo cual es un hallazgo real, y tampoco se cobró.

Sí, status es un vocabulario abierto. Evalúe según ok y trate todo lo demás como no respondido, y su código seguirá siendo correcto sin importar cómo crezca el vocabulario.

porting le da la fecha y el historial completo, mientras que la bandera ported de la consulta base solo indica si alguna vez hubo un cambio. classification resuelve line_type al servicio asignado exacto, desde una fuente diferente con un vocabulario más amplio, y se reporta por separado para que siempre pueda distinguir entre ambos.

Porque la red no proporcionó una cifra exacta. sim_swap devuelve min_days y max_days en lugar de last_swapped_at cuando solo se conoce una banda de recencia. porting hace algo similar: establece last_ported_at_is_approximate cuando un registro registra el período de un cambio pero no el día.

No. Significa que se consultó el registro y no tiene ningún cambio para este número, lo cual es un hallazgo sobre el número y no un vacío en la respuesta. El status del bloque es lo que le indica si la verificación se ejecutó o no.

Como una señal entre varias. Va de 0 para credibilidad baja a 100 para alta, es un valor compuesto y no se puede derivar de las demás propiedades. Evalúala junto con el resto de la respuesta en lugar de usarla como único criterio de decisión.

Si la dirección aceptará correo. Una sola llamada devuelve un veredicto en result, una puntuación de delivery_confidence, los indicadores que describen el tipo de dirección y una corrección cuando la dirección parece tener un error tipográfico.

valid significa que la dirección existe y acepta correo: envíe. neutral significa que no se pudo confirmar en ningún sentido, generalmente porque el dominio receptor responde igual a todos los destinatarios. risky significa que probablemente acepta correo pero tiene más probabilidades de rebotar o generar quejas. undeliverable significa que no acepta correo. typo significa que la dirección parece estar mal escrita.

reason indica cuál de tres problemas existe: invalid_syntax para una dirección con formato incorrecto, invalid_domain cuando el dominio no acepta correo en absoluto, e invalid_recipient cuando el dominio acepta correo pero este buzón no existe.

Ofrezca did_you_mean a quien escribió la dirección original en lugar de enviar a ella sin preguntar. La corrección es una suposición, y la dirección que pretendían puede no ser ninguna de las dos.

Va de 0, certeza de que no se entregará, a 100, certeza de que sí. La misma puntuación puede aparecer bajo distintos veredictos por diferentes razones, así que léala junto con result en vez de en su lugar. Es el campo en el que apoyarse cuando quiere un solo umbral para todos los veredictos, incluidos los que se añadan en el futuro.

No, y la diferencia importa. El campo valid es más limitado: indica si la dirección tiene un formato correcto y si su dominio está configurado para recibir correo. No dice nada sobre el buzón, por lo que una dirección con un dominio funcional pero sin buzón existente será true ahí y undeliverable en result.

role significa que la dirección nombra una función en lugar de una persona, como support@ o info@, por lo que las respuestas y el consentimiento son ambiguos y las quejas más probables. disposable indica un proveedor de direcciones desechables, así que la dirección normalmente dejará de existir. free_provider indica un proveedor de correo para consumidores como Gmail u Outlook.com, lo cual solo es una señal cuando esperaba una dirección empresarial.

Envíe la dirección tal cual, exactamente como la tiene. Un formato con nombre visible, con un nombre delante y la dirección entre corchetes angulares, se rechaza en lugar de descomponerse, porque descomponerla consultaría una dirección que usted no envió. La parte antes del arroba se pasa tal como está escrita, y cambiar sus mayúsculas puede cambiar el delivery_confidence que obtiene.

No. Las supresiones lo hacen automáticamente y de forma gratuita, para direcciones que ya rebotaron o generaron quejas. Use Lookup para las direcciones a las que aún no ha enviado, en el registro o antes de actuar sobre un lead.