Quickstart
Primer request serio en menos de 5 minutos
Activa tu workspace free en /perfil/api, crea tu key y prueba primero con filtros deterministas. En free, `q` no tiene la misma promesa operativa que filtros como `city`, `date_from` o `category`.
curl -H "X-API-Key: parch_demo_live_xxxxx" \
"https://api.parchar.ai/api/v1/events?country_code=CO&city=bogota&date_from=2026-04-18&limit=20" Contrato operativo
Lo que sí prometemos
- Autenticación por `X-API-Key` sobre `/api/v1`.
- Free usa cache más agresivo y shaping más conservador que paid.
- El horizonte hacia futuro depende del plan: 30 días en free, 180 en Build, 365 por cohorte en Enterprise.
- Cuando una fuente cae o pierde confianza, el API sirve el último snapshot bueno con `freshness_status = stale | frozen` en vez de inventar frescura.
- Campos de baja confianza pueden ocultarse o degradarse; el contrato prioriza seguridad del dato sobre exhaustividad.
Antes de subir a paid
Free es útil para validar fit. Paid se vende por menor cache, mejor freshness, provenance más rica, sync incremental y soporte por cohorte, no por “real-time” vacío.
Planes y promesas
Free
Self-serve
60 req/min · 1,000 req/día · 30,000 req/mes
Sirve para prototipos serios, asistentes y discovery. Respuestas más cacheadas, horizonte de 30 días y sin source trace.
- 1 key activa
- limit <= 20
- sin /changes
- sin SLA contractual
Build
Paid
120 req/min · 5,000 req/día · 100,000 req/mes
Pensado para equipos que ya necesitan `/changes`, source trace y una ventana operativa más corta sin fingir tiempo real extremo.
- 2 keys
- limit <= 100
- incluye /changes
- SLA objetivo 99.5%
Growth
Paid
300 req/min · 50,000 req/día · 1,000,000 req/mes
Abre webhooks, exports firmados y metadata más rica para partners que ya operan sincronización y reporting sobre el catálogo.
- 5 keys
- webhooks
- signed exports
- SLA objetivo 99.9%
Enterprise
Cohort-based
Cuotas y cohortes negociadas
No vendemos una promesa uniforme para toda LatAm. Se pacta por ciudades, fuentes y canales concretos.
- limit <= 250
- cohortes dedicadas
- dumps firmados
- soporte operativo
Endpoints principales
Catálogo principal
La capa core para polling controlado y discovery estructurado.
GET /api/v1/events
GET /api/v1/events/:id
GET /api/v1/venues/:id
GET /api/v1/cities
GET /api/v1/categories
Confiabilidad y freshness
Sirve para medir la salud del inventario publicado sin leer internals del scraper.
GET /api/v1/meta/status
GET /api/v1/meta/freshness
Sync incremental y provenance
Disponible en planes pagos para integraciones que no quieren reconsultar todo el catálogo.
GET /api/v1/changes
GET /api/v1/sources/:id
Filtros y request shaping
La recomendación operativa es empezar por filtros deterministas. La mayoría de integraciones B2B no necesitan full-text pesado para arrancar: necesitan consistencia por ciudad, fecha y categoría.
Nota sobre `q`
Existe para discovery, pero en free no lleva la misma promesa operativa que los filtros estructurados. Si tu producto depende de sync confiable, usa `/changes`, `updated_since` y cohortes concretas.
Respuesta útil incluso con incertidumbre
El payload siempre intenta ser útil aunque la certeza no sea perfecta. En vez de esconder incertidumbre, la exponemos con signals de calidad para que tu ranking, UI o agente conversacional pueda decidir.
{
"success": true,
"data": [
{
"id": "evt_01jz2x9w0m",
"title": "Concierto en Chapinero",
"start_at": "2026-04-20T20:00:00-05:00",
"timezone": "America/Bogota",
"category": "concierto",
"city": "bogota",
"canonical_city_slug": "bogota",
"country_code": "CO",
"attendance_mode": "in_person",
"event_status": "active",
"partner_taxonomy": {
"primary": "music",
"events_com_category": "Music"
},
"venue": {
"id": "ven_01jy9w0m2k",
"name": "Teatro ejemplo",
"latitude": 4.651,
"longitude": -74.057
},
"source_count": 2,
"source_last_verified_at": "2026-04-18T08:42:00Z",
"image_attribution": {
"label": "Fuente original",
"source_host": "teatroejemplo.com"
},
"tags": ["concierto", "music", "bogota"],
"quality": {
"confidence_score": 0.94,
"freshness_status": "fresh",
"last_checked_at": "2026-04-18T08:42:00Z",
"source_verified": true,
"reported_or_inferred": "reported",
"degraded_reason": null
}
}
],
"meta": {
"plan": "free",
"page": 1,
"limit": 20,
"total": 318,
"has_more": true,
"applied_future_horizon_days": 30
}
}Contrato exportable
Si vas a integrar en serio, no dependas solo de esta página. Descarga el contrato OpenAPI y versiona ese artefacto junto con tu cliente, tu SDK interno o tus tests de integración.
Artefactos públicos: https://api.parchar.ai/api/public/data-api/openapi.json y https://api.parchar.ai/api/public/data-api/postman.json
SDK TypeScript de referencia
También mantenemos un cliente TypeScript alineado con el mismo contrato: @parchar/data-api-client. Hoy vive dentro del repo y sirve como wrapper ligero sobre fetch, no como una especificación paralela.
import { createParcharDataApiClient } from "@parchar/data-api-client";
const client = createParcharDataApiClient({
apiKey: process.env.PARCHAR_API_KEY!,
});
const response = await client.listEvents({
country_code: "CO",
city: "bogota",
date_from: "2026-04-18",
limit: 20,
});
console.log(response.data[0]?.quality.freshness_status);
console.log(response.rateLimit.remaining_minute); La regla sigue siendo la misma: el OpenAPI es la fuente de verdad y el SDK se mantiene pegado a ese contrato para no inventar una experiencia distinta de la API real.
Polling incremental y cambios
Cuando tu integración deja de ser exploratoria, el cambio correcto no es “polling más agresivo” sino pasar a `/changes` y a canales de salida. Build abre ese primer carril.
curl -H "X-API-Key: parch_build_live_xxxxx" \
"https://api.parchar.ai/api/v1/changes?updated_since=2026-04-17T00:00:00Z&limit=100" El feed de cambios se construye sobre `published_event_changes`, no sobre filas crudas del scraper. Eso significa menos ruido, más trazabilidad y degradación coherente con el serving layer.
Webhooks, exports y surfaces complementarias
Webhooks
Growth y Enterprise pueden recibir cambios derivados de `published_event_changes`, con firma, retries y replay auditable desde el portal.
Exports firmados
Growth y Enterprise pueden pedir snapshots JSONL/CSV de `published_events` sin saltarse el publish gate ni la trazabilidad.
Status público
La salud visible del producto vive en `/api/status`, no en screenshots de admin. Ahí se publica freshness, degradación y comportamiento del publish gate.
Ejemplo en JavaScript
Este primer ejemplo sirve para un backend Node, un worker o un job de sync. Empieza con filtros estructurados y deja que `quality.*` gobierne tus decisiones de ranking o fallback.
const response = await fetch(
"https://api.parchar.ai/api/v1/events?country_code=CO&city=bogota&date_from=2026-04-18&limit=20",
{
headers: { "X-API-Key": process.env.PARCHAR_API_KEY! }
}
);
if (!response.ok) throw new Error(`Parchar API error: ${response.status}`);
const payload = await response.json();
console.log(payload.data[0]?.quality?.freshness_status);Ejemplo en Python
Útil para pipelines, agentes o integraciones internas. Si subes a Build o Growth, el siguiente paso correcto es sumar `/changes` y luego webhooks, no bajar el intervalo de polling sin control.
import os
import requests
response = requests.get(
"https://api.parchar.ai/api/v1/events",
params={
"country_code": "CO",
"city": "bogota",
"date_from": "2026-04-18",
"limit": 20,
},
headers={"X-API-Key": os.environ["PARCHAR_API_KEY"]},
timeout=20,
)
response.raise_for_status()
payload = response.json()
print(payload["data"][0]["quality"]["freshness_status"])Developer portal y estado público
El portal self-serve y la página de status completan la experiencia. Uno sirve para activar, asegurar y crecer tu workspace; el otro para entender la salud del servicio sin entrar a admin.
Capa pública secundaria
Seguimos exponiendo superficies públicas y feeds para discovery, citation y SEO. Esa capa no reemplaza la Event Data API autenticada; la complementa.
GET /api/public/events
GET /api/public/cities
GET /api/public/stats
GET /api/public/data-api/status
GET https://parchar.ai/events-feed.json
GET https://parchar.ai/rss.xml