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 si prometemos
- Autenticacion por `X-API-Key` sobre `/api/v1`.
- Free usa cache mas agresivo y shaping mas conservador que paid.
- El horizonte hacia futuro depende del plan: 30 dias en free, 180 en Build, 365 por cohorte en Enterprise.
- Cuando una fuente cae o pierde confianza, el API sirve el ultimo 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 util para validar fit. Paid se vende por menor cache, mejor freshness, provenance mas rica, sync incremental y soporte por cohorte, no por “real-time” vacio.
Planes y promesas
Free
Self-serve
60 req/min · 1,000 req/dia · 30,000 req/mes
Sirve para prototipos serios, asistentes y discovery. Respuestas mas cacheadas, horizonte de 30 dias y sin source trace.
- 1 key activa
- limit <= 20
- sin /changes
- sin SLA contractual
Build
Paid
120 req/min · 5,000 req/dia · 100,000 req/mes
Pensado para equipos que ya necesitan `/changes`, source trace y una ventana operativa mas corta sin fingir tiempo real extremo.
- 2 keys
- limit <= 100
- incluye /changes
- SLA objetivo 99.5%
Growth
Paid
300 req/min · 50,000 req/dia · 1,000,000 req/mes
Abre webhooks, exports firmados y metadata mas rica para partners que ya operan sincronizacion y reporting sobre el catalogo.
- 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
Catalogo 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 catalogo.
GET /api/v1/changes
GET /api/v1/sources/:id
Filtros y request shaping
La recomendacion operativa es empezar por filtros deterministas. La mayoria de integraciones B2B no necesitan full-text pesado para arrancar: necesitan consistencia por ciudad, fecha y categoria.
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 util incluso con incertidumbre
El payload siempre intenta ser util 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 pagina. Descarga el contrato OpenAPI y versiona ese artefacto junto con tu cliente, tu SDK interno o tus tests de integracion.
Artefactos publicos: 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
Tambien 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 especificacion 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 integracion deja de ser exploratoria, el cambio correcto no es “polling mas 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, mas trazabilidad y degradacion 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 publico
La salud visible del producto vive en `/api/status`, no en screenshots de admin. Ahí se publica freshness, degradacion 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
Util 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 publico
El portal self-serve y la pagina 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 publica secundaria
Seguimos exponiendo superficies publicas 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