Skip to main content
La API GraphQL expone un subconjunto compatible de las capacidades REST de Ayrshare a través de un único endpoint. Cada campo expuesto llama al mismo controlador subyacente que su equivalente REST, por lo que la autenticación, los permisos del plan, las cuotas y los datos de respuesta siguen el comportamiento de REST. REST sigue siendo la API más amplia; usa el esquema o el Explorer para ver exactamente qué operaciones admite GraphQL. Lo que aporta es la posibilidad de pedir varias cosas en una sola solicitud y de descubrir la superficie GraphQL compatible actual desde el propio esquema, sin leer la documentación página por página. El esquema describe cada campo de solicitud compatible y las selecciones tipadas disponibles en las respuestas estructuradas; las operaciones que devuelven el envoltorio REST como JSON conservan la carga útil completa.
Envía un POST con un cuerpo JSON que contenga una query, exactamente igual que con cualquier endpoint GraphQL. GET y DELETE devuelven 405 Method Not Allowed: las consultas mediante GET son opcionales en la especificación de GraphQL y no se admiten aquí.

Tu primera consulta

La respuesta es el mismo envoltorio JSON que devuelve el endpoint REST de historial, dentro del campo data de GraphQL:

Pedir varias cosas a la vez

El motivo para recurrir a GraphQL es una solicitud como esta, que equivaldría a cuatro llamadas REST:
Un solo viaje de ida y vuelta devuelve las cuatro. Ten en cuenta que se trata de cuatro campos de operación raíz y cuatro llamadas a la API a efectos de facturación, no una. Seleccionar campos anidados de la respuesta no añade llamadas; consulta Límites y facturación.

Autenticación

Idéntica a REST. Envía tu API Key como token bearer:
Si tu cuenta usa User Profiles, las operaciones que exponen profileKey pueden seleccionar un perfil de cualquiera de estas dos formas:
  • Envía Profile-Key como valor predeterminado para toda la solicitud.
  • Pasa profileKey en un campo concreto para sobrescribir ese valor predeterminado, lo que permite que una solicitud actúe sobre más de un perfil.
Cuando ambos están presentes, prevalece el argumento del campo. Los campos de nivel de cuenta o exclusivos de la cuenta principal no exponen profileKey y pueden rechazar un encabezado Profile-Key; por ejemplo, createProfile debe usar la API Key principal sin ese encabezado. Revisa la definición de cada campo en el esquema para conocer su alcance, y consulta Gestionar varios usuarios para saber cómo funcionan las Profile Keys.

Pruébalo sin escribir código

El GraphQL Explorer es un navegador interactivo del esquema actual. Muestra todas las operaciones GraphQL disponibles con sus argumentos y descripciones, autocompleta mientras escribes y ejecuta consultas contra tu cuenta. No necesitas una API Key para explorar el esquema: el esquema es público, igual que esta documentación. Sí la necesitas para ejecutar una consulta, porque cada operación pasa por la misma autenticación que REST.

¿Deberías usar GraphQL o REST?

REST sigue siendo la interfaz principal y aquella en torno a la cual se construyen la mayor parte de nuestra documentación, los SDKs y las integraciones. Recurre a GraphQL cuando:
  • Necesites varios datos no relacionados y quieras obtenerlos en un solo viaje de ida y vuelta.
  • Quieras nombres de operación, argumentos, objetos de entrada, enums y selecciones de respuesta tipadas legibles por máquina. La mayoría de las respuestas siguen siendo JSON para conservar el envoltorio REST completo; createPost devuelve actualmente un PostResult tipado.
  • Estés explorando la API y quieras ver lo que existe sin moverte entre páginas de documentación.
Quédate con REST cuando:
  • Estés subiendo archivos. Los bytes de los medios no pueden viajar en una solicitud GraphQL; consulta Subir medios para conocer la vía compatible.
  • Estés usando uno de nuestros SDKs o integraciones no-code, que hablan REST.
  • Quieras la menor cantidad posible de dependencias. Una llamada REST no necesita nada más que un cliente HTTP.
Ambas interfaces se admiten en paralelo, y puedes combinarlas libremente en la misma integración.
  • Usar la API: encontrar operaciones, tipos de argumentos y subir medios.
  • Errores: qué fallos cambian el estado HTTP, por qué las operaciones fallidas siguen devolviendo HTTP 200 y cómo gestionar el éxito parcial.
  • Límites y facturación: límites de tamaño de las consultas y cómo se cuentan las solicitudes.