Descubre qué es una API en WordPress y cómo funciona para conectar tu web con herramientas externas como CRM, email marketing y sistemas de pago.
La API REST de WordPress es la puerta estándar para leer y escribir datos del sitio desde fuera del escritorio: otras webs, CRMs, ERPs, apps móviles o un frontend en React. Desde WordPress 4.7 forma parte del núcleo, así que no hace falta un plugin solo para «activar la API». Lo que sí hace falta es entender endpoints, autenticación y límites antes de conectar sistemas de verdad.
Esta guía une la visión práctica (conectar CRM, email y pagos) con el funcionamiento interno de la API: rutas, peticiones, register_rest_route y seguridad. Si buscas una base sólida para integrar WordPress con el resto de tu stack, este es el mapa.
En proyectos reales la API rara vez se usa «sola»: convive con colas, logs, reintentos y un acuerdo claro de quién escribe qué campo. Tratarla como un cable mágico entre dos paneles es la forma más rápida de acumular inconsistencias de datos.
Qué es la API REST de WordPress y por qué existe
Una API (Application Programming Interface) define cómo dos programas intercambian datos. En WordPress, la API REST expone contenido y operaciones mediante HTTP y respuestas JSON. En la práctica: pides /wp-json/wp/v2/posts y recibes entradas; envías un POST autenticado y creas una nueva.
Existe porque el panel de administración no escala bien como único canal de integración. Negocios y agencias necesitan sincronizar contactos con HubSpot, empujar pedidos a un ERP, alimentar una app o montar un headless con Next.js. La API REST estandariza ese intercambio sin scrapear HTML ni tocar la base de datos a mano.
WordPress tiene otras APIs internas (Plugin API, Theme API) y el legado XML-RPC, aún presente en algunos flujos antiguos. Para integraciones externas modernas, la REST API es la vía habitual: HTTP, JSON y la misma semántica de recursos que usan casi todos los servicios web actuales.
También conviene separar dos preguntas: «¿puedo leer este recurso?» y «¿debo escribirlo desde fuera?». Muchas webs solo necesitan lectura pública de posts o productos; otras exigen escritura controlada desde un middleware. Diseñar esa frontera evita abrir más superficie de la necesaria.
Conceptos: REST, endpoints, rutas y recursos
REST (Representational State Transfer) organiza el servicio alrededor de recursos y verbos HTTP: GET lee, POST crea, PUT/PATCH actualiza y DELETE elimina. WordPress adopta ese modelo para posts, páginas, usuarios, medios y taxonomías.
Un endpoint es una URL concreta que acepta peticiones. La base es /wp-json/; el namespace del núcleo vive en /wp-json/wp/v2/. Rutas nativas habituales:
/wp-json/wp/v2/posts— entradas/wp-json/wp/v2/pages— páginas/wp-json/wp/v2/users— usuarios/wp-json/wp/v2/categories— categorías/wp-json/wp/v2/media— multimedia/wp-json/wp/v2/comments— comentarios
Un recurso es la entidad (una entrada, un usuario). Su representación es el JSON que devuelve la API: título, contenido, fechas, autor, estado, meta y enlaces relacionados (_links). Puedes acotar campos con ?_fields=id,title,link para reducir payload y exposición.
WooCommerce añade su propio namespace (/wp-json/wc/v3/) para productos, pedidos y clientes. El patrón es el mismo; cambian rutas y el modelo de claves API de la tienda.
Los CPT y taxonomías propias aparecen en la API si el tipo de contenido se registró con show_in_rest. Si un recurso «no sale» en /wp-json/, casi siempre es un detalle de registro, no un fallo misterioso del núcleo.
Cómo funciona una petición (ejemplo con /wp-json/wp/v2/posts)
Flujo interno típico:
- Recepción: las rewrite rules envían lo que llega bajo
/wp-json/al servidor REST. - Enrutamiento:
WP_REST_Serverempareja método + ruta con un endpoint registrado. - Permisos: se ejecuta el callback de
permission_callback. - Procesamiento: el callback lee o escribe (consulta WP_Query, inserta un post, etc.).
- Respuesta: JSON con código HTTP (
200,201,401,403,404…).
Ejemplo de lectura pública (sin autenticación si el contenido está publicado):
GET https://tusitio.com/wp-json/wp/v2/posts?per_page=5&orderby=date
Respuesta resumida (estructura real más amplia):
[
{
"id": 42,
"date": "2026-03-10T09:00:00",
"slug": "ejemplo",
"status": "publish",
"link": "https://tusitio.com/tutoriales-avanzados/ejemplo/",
"title": { "rendered": "Ejemplo de entrada" },
"content": { "rendered": "<p>…</p>", "protected": false }
}
]
Para crear contenido necesitas autenticación y el método adecuado:
POST /wp-json/wp/v2/posts
Content-Type: application/json
{
"title": "Nueva entrada vía API",
"content": "Texto del cuerpo",
"status": "draft"
}
En depuración, herramientas como Postman o Insomnia ayudan a inspeccionar cabeceras, códigos y el cuerpo JSON sin montar aún el cliente definitivo.
Cuando algo falla, mira en este orden: código HTTP, cuerpo de error de WordPress (code, message), cabeceras CORS si llamas desde el navegador, y por último la consulta SQL que dispara tu callback. El 90 % de los «la API no funciona» son permisos, nonce caducado o una ruta mal escrita.
Autenticación: cookies + nonce, contraseñas de aplicación, JWT/OAuth
Leer contenido público suele ser anónimo. Crear, editar o borrar exige identidad y capacidad. Opciones habituales:
- Cookies + nonce: el flujo nativo cuando la petición sale del propio admin o del front con usuario logueado. La cookie de sesión va acompañada de un nonce (cabecera
X-WP-Nonce). Cómodo en el ecosistema WP; poco práctico para un CRM externo. - Application Passwords: desde WordPress 5.6 puedes generar una contraseña de aplicación por usuario. Ideal para integraciones servidor-a-servidor con Basic Auth sobre HTTPS. Revocas la clave sin cambiar la contraseña de login.
- JWT / OAuth: útiles cuando hay app de usuario final, sesión propia o varios clientes. Implican plugins o capas extra (emisión de tokens, caducidad, refresh). Más control; más superficie que mantener.
Ejemplo de cabecera con Application Password (el usuario y la clave van en Base64; siempre por HTTPS):
Authorization: Basic base64(usuario:xxxx xxxx xxxx xxxx xxxx xxxx)
Regla práctica: no expongas escritura sin permission_callback estricto; no reutilices la contraseña de administrador en scripts; rota claves cuando un proveedor o un empleado deja el proyecto. Wordfence y auditorías similares llevan años señalando APIs mal cerradas como vector habitual.
En agencias, un patrón sano es un usuario técnico con rol mínimo (o capacidades a medida) dedicado a la integración, Application Password propia y registro de qué sistema la usa. Así auditas y revocas sin tocar las cuentas de las personas.
Crear endpoints personalizados (register_rest_route)
Los endpoints nativos no cubren todo: informes internos, payloads a medida para un ERP o lecturas que mezclan CPT + meta. Ahí entra register_rest_route() en el hook rest_api_init.
Tres piezas: namespace (evita choques, p. ej. mi-plugin/v1), ruta (/pedidos-resumen) y callbacks (lógica + permisos). Conviene declarar esquema de argumentos (tipo, required, sanitize) para validar entrada y documentar en /wp-json/.
add_action( 'rest_api_init', function () {
register_rest_route(
'mi-plugin/v1',
'/pedidos-resumen',
array(
'methods' => 'GET',
'callback' => 'mi_plugin_pedidos_resumen',
'permission_callback' => function () {
return current_user_can( 'manage_woocommerce' );
},
'args' => array(
'desde' => array(
'required' => false,
'type' => 'string',
'sanitize_callback' => 'sanitize_text_field',
),
),
)
);
} );
function mi_plugin_pedidos_resumen( WP_REST_Request $request ) {
$desde = $request->get_param( 'desde' );
// Consulta agregada (ejemplo): totales del periodo.
$data = array(
'desde' => $desde,
'total' => 128,
'importe' => 15420.50,
);
return rest_ensure_response( $data );
}
Buenas prácticas: namespaces versionados (/v1, /v2), errores con WP_Error y códigos claros, y caché en lecturas pesadas. Un endpoint «cómodo» que devuelve medio sitio sin autenticación es deuda técnica desde el día uno.
Si el consumidor es un ERP lento, no le ofrezcas un JSON de 2 MB «por si acaso». Pagina, filtra por fecha de modificación y documenta el contrato. Un endpoint estrecho y estable supera a uno genérico que cambia cada sprint.
API REST vs webhooks
Se complementan; no son lo mismo. La API REST es pull: tú preguntas cuando quieres datos. Un webhook es push: el sistema avisa cuando ocurre un evento (pedido completado, usuario registrado).
| Escenario | API REST | Webhook |
|---|---|---|
| Sincronizar catálogo a demanda | Ideal | Poco eficiente |
| Avisar de una venta al instante | Ineficiente (polling) | Ideal |
| Informes y consultas ad hoc | Ideal | No aplica |
| Actualizar stock al vender | Posible | Recomendado |
En WooCommerce es habitual: webhook de «pedido completado» hacia el ERP y, además, lecturas REST para reconciliar inventario por la noche. Diseña el flujo por latencia y volumen, no por moda.
Los webhooks también fallan: el receptor cae, el certificado caduca, el evento se duplica. Necesitas idempotencia y una cola de reintentos. La API REST encaja bien como vía de recuperación cuando el push no llegó.
Casos reales: CRM, email marketing, pagos, ERP
CRM. Altas de formulario o clientes WooCommerce se crean o actualizan en HubSpot/Salesforce vía API. Evitas CSV manuales y mantienes al comercial con el mismo contacto que llegó por la web. El diseño importa: idempotencia, mapeo de campos y qué sistema es «fuente de verdad».
Email marketing. Un registro o una compra dispara el alta en Mailchimp, ActiveCampaign o similar. Puedes hacerlo con REST hacia el proveedor, con su plugin, o con un webhook saliente de WordPress/WooCommerce. El objetivo es la misma lista sin exportar a mano.
Pagos. Stripe, PayPal o Redsys hablan por API (a menudo vía pasarela WooCommerce): cobro, reembolso, estado del pedido. Tu tienda no inventa el protocolo PCI; orquesta estados y emails según la respuesta del proveedor.
ERP / inventario. Lectura de productos y escritura de stock o pedidos. Aquí fallan los proyectos que no contemplan rate limits, colas y reintentos. Mejor un job acotado que mil peticiones concurrentes desde el checkout.
Headless y móviles. React, Vue, Next o apps nativas consumen JSON para pintar contenido o gestionar cuentas. WordPress sigue siendo el CMS; la API es el contrato. Mismos cuidados de auth y de no filtrar campos sensibles en usuarios.
En headless, define desde el principio el modelo editorial (quién publica, previsualización, menús, redirecciones). La API resuelve datos; no sustituye una IA de contenido ni una estrategia de caché en el edge.
Seguridad y limitaciones
Exposición. Por defecto hay datos que quizá no quieras públicos (pistas de usuarios, campos de CPT mal registrados). Filtra con _fields, register_rest_field consciente y permission_callback reales — __return_true en escritura es un incidente esperando fecha.
Rate limiting. El núcleo no trae un limitador universal. En tráfico alto añade límites (CDN, firewall, plugin o capa propia) y cachea lecturas estables.
Rendimiento. Cada hit a /wp-json/ arranca WordPress y plugins. Endpoints pesados sin caché compiten con el front. Mide; no asumas que «como es API, no cuenta».
Versiones y cambios. Actualizaciones de WP, WooCommerce o tu plugin pueden alterar formas de respuesta. Versiona tus namespaces y monitoriza integraciones críticas tras cada deploy.
HTTPS y secretos. Application Passwords y tokens solo por TLS. Nada de claves en repos front públicos ni en tickets de soporte.
Si desactivas endpoints «por miedo», rompes el editor de bloques, apps oficiales y muchos plugins. Mejor endurecer (auth, campos, rate limit) que apagar la API entera sin medir el impacto.
FAQ
¿La API REST viene activada por defecto?
Sí. Desde WordPress 4.7 forma parte del núcleo. No necesitas un plugin solo para habilitarla. Sí puedes restringir o extender rutas con código o plugins de seguridad.
¿Puedo usar la API REST con WooCommerce?
Sí. WooCommerce expone endpoints bajo /wp-json/wc/v3/ (productos, pedidos, clientes, cupones…). Suele autenticarse con las claves API de WooCommerce, distintas de un usuario Application Password genérico.
¿Es seguro dejar la API REST accesible?
La lectura de contenido público está pensada para serlo. El riesgo está en escritura mal protegida, campos sensibles expuestos o claves filtradas. Revisa permisos, minimiza el JSON y mantén HTTPS.
Como cierre operativo: empieza por inventario de lecturas y escrituras, elige auth acorde al consumidor, versiona tus rutas propias y deja métricas (errores 4xx/5xx, latencia, volumen). La API REST de WordPress es madura; el riesgo casi nunca es «que exista», sino integrarla sin contrato ni observabilidad.
Si estás planteando una integración con CRM, ERP o un front desacoplado y quieres que el contrato de la API quede bien cerrado desde el principio, trabajo precisamente en integraciones API sobre WordPress.
¿Necesitas ayuda con tu proyecto? Trabajo con negocios y agencias en WordPress, WooCommerce, IA e integraciones. Escríbeme y lo vemos juntos.
