[{"data":1,"prerenderedAt":43},["ShallowReactive",2],{"article-introduccion-a-las-api-y-su-papel-en-la-integracion-de-sistemas":3},{"editorial_managed":4,"editorial_preview":5,"editorial_type":6,"title":7,"slug":8,"href":9,"description":10,"category":11,"category_slug":12,"author":13,"date":14,"updated_at":15,"read_time":16,"cover_image":17,"cover_alt":12,"cover_width":18,"cover_height":19,"cover_small":12,"social_alt":12,"preview_image":17,"social_image":17,"social_width":18,"social_height":19,"social_type":20,"seo_title":7,"seo_description":10,"html":21,"toc":22,"related":41,"tags":42},true,false,"Explicación","Qué es una API y cómo conecta sistemas","introduccion-a-las-api-y-su-papel-en-la-integracion-de-sistemas","\u002Fes-mx\u002Frecursos\u002Fintroduccion-a-las-api-y-su-papel-en-la-integracion-de-sistemas","Entiende qué es una API con un pedido que pasa entre sistemas, qué hace una integración y qué conviene preguntar antes de desarrollarla.","Artículos","","Acinsoft","2023-02-07 12:45:08","2026-09-17 00:00:00",5,"\u002Fimages\u002Feditorial-20260913\u002F056-social.jpg",1200,630,"image\u002Fjpeg","\u003Cp class=\"lead\">Una API define cómo un programa puede pedir información o solicitar una acción a otro componente. En un negocio, puede servir para que la tienda consulte existencias o para registrar un pago sin volver a capturarlo a mano.\u003C\u002Fp>\n\u003Cp>La sigla significa interfaz de programación de aplicaciones. Existen API de distintos tipos; aquí nos concentramos en las que permiten conectar sistemas a través de la web. La definición no implica que cualquier dato de una aplicación esté disponible. \u003Ca href=\"https:\u002F\u002Fdeveloper.mozilla.org\u002Fen-US\u002Fdocs\u002FGlossary\u002FAPI\" target=\"_blank\" rel=\"noopener noreferrer\">Definición de API en MDN\u003C\u002Fa>.\u003C\u002Fp>\n\u003Ch2 id=\"articulo-seccion-1\">Un pedido que pasa de la tienda al sistema de trabajo\u003C\u002Fh2>\n\u003Cp>\u003Cstrong>Ejemplo hipotético:\u003C\u002Fstrong> una empresa recibe un pedido en su tienda y alguien vuelve a escribir productos y cantidades en el sistema que utiliza el almacén. Una integración podría transmitir esos datos y registrar la respuesta, siempre que ambos sistemas permitan las operaciones necesarias.\u003C\u002Fp>\n\u003Cfigure class=\"flow\">\u003Cdiv>Tienda: pedido recibido\u003C\u002Fdiv>\u003Cspan aria-hidden=\"true\">↓\u003C\u002Fspan>\u003Cdiv>Integración: revisar y enviar datos\u003C\u002Fdiv>\u003Cspan aria-hidden=\"true\">↓\u003C\u002Fspan>\u003Cdiv>Sistema de almacén: aceptar o informar un problema\u003C\u002Fdiv>\u003Cfigcaption>Flujo conceptual propuesto. Una respuesta de error también forma parte de la integración.\u003C\u002Ffigcaption>\u003C\u002Ffigure>\n\u003Cp>Antes de programarlo hay preguntas del negocio: ¿quién manda sobre el inventario?, ¿qué ocurre si un producto tiene nombres diferentes?, ¿cuándo se considera aceptado el pedido? La API ofrece las operaciones; el proyecto debe establecer las reglas que conectan el trabajo de ambos lados.\u003C\u002Fp>\n\u003Ch2 id=\"articulo-seccion-2\">Consultar y recibir un aviso son cosas distintas\u003C\u002Fh2>\n\u003Cp>Una aplicación puede consultar otra para obtener un dato. También puede recibir una notificación cuando ocurre algo; este mecanismo suele llamarse \u003Cem>webhook\u003C\u002Fem>. Por ejemplo, Stripe documenta avisos sobre pagos y otros eventos para que una aplicación reaccione sin depender de que una persona revise el panel. \u003Ca href=\"https:\u002F\u002Fdocs.stripe.com\u002Fwebhooks\" target=\"_blank\" rel=\"noopener noreferrer\">Documentación de webhooks de Stripe\u003C\u002Fa>.\u003C\u002Fp>\n\u003Cp>En esa misma documentación, Stripe advierte que pueden recibirse eventos duplicados y que su entrega no garantiza el orden. Por eso una integración de pagos debe identificar lo que ya procesó y verificar el estado pertinente. Recibir dos avisos no debería convertirse en dos registros de la misma operación.\u003C\u002Fp>\n\u003Cp>Este ejemplo corresponde a Stripe. Los mecanismos, permisos y comportamiento deben verificarse en la documentación del proveedor que realmente utilizará el proyecto.\u003C\u002Fp>\n\u003Cdiv class=\"table-wrap\">\u003Ctable tabindex=\"0\" aria-label=\"Tabla de referencia\">\u003Ccaption>Dos formas de iniciar el trabajo entre sistemas\u003C\u002Fcaption>\u003Cthead>\u003Ctr>\u003Cth scope=\"col\">Forma\u003C\u002Fth>\u003Cth scope=\"col\">Ejemplo en el pedido\u003C\u002Fth>\u003Cth scope=\"col\">Qué debe quedar definido\u003C\u002Fth>\u003C\u002Ftr>\u003C\u002Fthead>\u003Ctbody>\u003Ctr>\u003Cth scope=\"row\">Consulta a la API\u003C\u002Fth>\u003Ctd>La integración pregunta por el estado del pedido.\u003C\u002Ftd>\u003Ctd>Cuándo consulta, qué permisos tiene y qué hace si no obtiene respuesta.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Cth scope=\"row\">Aviso por webhook\u003C\u002Fth>\u003Ctd>El sistema avisa que ocurrió un cambio.\u003C\u002Ftd>\u003Ctd>Cómo se verifica el aviso, cómo se evitan duplicados y cuándo consultar el estado actualizado.\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003C\u002Fdiv>\n\u003Ch2 id=\"articulo-seccion-3\">Un aviso repetido no debería crear otro pedido\u003C\u002Fh2>\n\u003Cp>En nuestro ejemplo hipotético, el pedido tiene la referencia \u003Ccode>P-1002\u003C\u002Fcode>. La integración registra esa referencia y el resultado del envío. Si pierde la respuesta del almacén, no puede concluir automáticamente que el registro falló: necesita comprobar qué ocurrió antes de repetir una operación que podría crear otro pedido.\u003C\u002Fp>\n\u003Col>\u003Cli>\u003Cstrong>Pedido recibido:\u003C\u002Fstrong> valida los productos y cantidades necesarios.\u003C\u002Fli>\u003Cli>\u003Cstrong>Envío al almacén:\u003C\u002Fstrong> conserva la referencia y la respuesta que permita relacionar ambos sistemas.\u003C\u002Fli>\u003Cli>\u003Cstrong>Respuesta incierta o aviso repetido:\u003C\u002Fstrong> consulta o reconoce la operación existente según las capacidades del proveedor; no crea otra a ciegas.\u003C\u002Fli>\u003Cli>\u003Cstrong>Error que requiere revisión:\u003C\u002Fstrong> deja el caso pendiente con una causa y una persona responsable, sin marcarlo como terminado.\u003C\u002Fli>\u003C\u002Fol>\n\u003Cp>Diseñar un reintento para que no repita su efecto se conoce como \u003Cem>idempotencia\u003C\u002Fem>. No basta con guardar un número en una tabla: el mecanismo debe impedir duplicados también si llegan dos solicitudes al mismo tiempo. La referencia y el proceso anteriores son una propuesta conceptual, no un contrato que cualquier API ofrezca. La especificación HTTP explica por qué \u003Ca href=\"https:\u002F\u002Fwww.rfc-editor.org\u002Frfc\u002Frfc9110.html#section-9.2.2\" target=\"_blank\" rel=\"noopener noreferrer\">los reintentos dependen de la idempotencia de la operación\u003C\u002Fa>.\u003C\u002Fp>\n\u003Ch2 id=\"articulo-seccion-4\">Por qué “tener API” no termina la evaluación\u003C\u002Fh2>\n\u003Cp>Para decidir si la conexión sirve, pide comprobar tres cuestiones con una operación concreta:\u003C\u002Fp>\n\u003Cdl>\u003Cdt>La información disponible\u003C\u002Fdt>\u003Cdd>¿La API permite consultar o cambiar exactamente el dato necesario? Ver una pantalla del sistema no demuestra que exista una operación equivalente.\u003C\u002Fdd>\u003Cdt>Las reglas del negocio\u003C\u002Fdt>\u003Cdd>¿Qué sistema conserva el dato principal y cómo se resuelven diferencias? Un código de producto distinto puede requerir una equivalencia explícita.\u003C\u002Fdd>\u003Cdt>El trabajo cuando algo falla\u003C\u002Fdt>\u003Cdd>¿Dónde se registra el error, quién lo revisa y cómo se completa la operación pendiente sin duplicarla?\u003C\u002Fdd>\u003C\u002Fdl>\n\u003Cp>También conviene revisar las condiciones de acceso y mantenimiento de la API elegida. Un presupuesto de integración necesita contemplar su funcionamiento después del arranque, no sólo una demostración donde el envío salió bien.\u003C\u002Fp>\n\u003Cp>Antes de aceptar la entrega, prueba un pedido válido, un producto desconocido, una respuesta tardía y un aviso repetido. Define qué debe ver el equipo en cada caso. La guía sobre \u003Ca href=\"\u002Fes-mx\u002Frecursos\u002Fla-importancia-de-las-pruebas-de-integracion-y-como-realizarlas-correctamente\" rel=\"noopener noreferrer\">cómo comprobar una integración entre sistemas\u003C\u002Fa> desarrolla esta revisión.\u003C\u002Fp>\n\u003Ch2 id=\"articulo-seccion-5\">Cuándo vale la pena investigarlo\u003C\u002Fh2>\n\u003Cp>Busca una tarea repetida y describe cuánto trabajo implica. Si el mismo dato se copia entre sistemas con frecuencia, o los errores de captura producen correcciones constantes, tienes un proceso que vale la pena evaluar. Si casi no ocurre o requiere una decisión humana diferente cada vez, el beneficio de automatizarlo necesita una revisión más cuidadosa.\u003C\u002Fp>\n\u003Cp>Para comenzar basta con describir qué dispara la tarea, qué dato debe llegar a dónde y qué tendría que pasar después. Un ejemplo sin información sensible suele explicar mejor la necesidad que una lista de tecnologías.\u003C\u002Fp>\n\u003Cdiv class=\"cta\">\u003Ch2 id=\"articulo-seccion-6\">¿Estás capturando lo mismo en dos sistemas?\u003C\u002Fh2>\u003Cp>Cuéntanos cuáles son y qué información necesitas trasladar. Podemos conversar sobre una integración y qué convendría comprobar primero.\u003C\u002Fp>\u003Ca href=\"\u002Fes-mx\u002Fsoluciones\u002Fautomatizacion-integraciones\" rel=\"noopener noreferrer\">Conocer automatización e integraciones\u003C\u002Fa>\u003C\u002Fdiv>\n",[23,26,29,32,35,38],{"id":24,"title":25},"articulo-seccion-1","Un pedido que pasa de la tienda al sistema de trabajo",{"id":27,"title":28},"articulo-seccion-2","Consultar y recibir un aviso son cosas distintas",{"id":30,"title":31},"articulo-seccion-3","Un aviso repetido no debería crear otro pedido",{"id":33,"title":34},"articulo-seccion-4","Por qué “tener API” no termina la evaluación",{"id":36,"title":37},"articulo-seccion-5","Cuándo vale la pena investigarlo",{"id":39,"title":40},"articulo-seccion-6","¿Estás capturando lo mismo en dos sistemas?",[],[],1791093720022]