Developer docs

Event Data API para developers

Parchar.ai vende una infraestructura de eventos confiable para LatAm. No prometemos indexacion de milisegundos: prometemos cobertura, trazabilidad, degradacion honesta y un contrato estable sobre inventario publicado.

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"
Header: `X-API-Key` Base URL: `https://api.parchar.ai/api/v1` Listas cacheadas por plan

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

24-48h objetivo

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

6-24h segun fuente

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

3-24h segun mezcla de fuente

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

Por cohorte / fuente

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.

country_codecitydate_fromdate_tocategoryvenue_idbboxupdated_sincelimitpagesortq

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.

quality.confidence_scorequality.freshness_statusquality.last_checked_atquality.source_verifiedquality.reported_or_inferredquality.degraded_reasoncanonical_city_slugattendance_modepartner_taxonomy.events_com_categorysource_countsource_last_verified_atimage_attribution.source_host
{
  "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