Cuando algo no sale
El orden de abajo no es arbitrario: va de gratis a caro y de lo que podés ver vos a lo que tenemos que mirar nosotros. Los dos primeros pasos resuelven la mayoría de los casos y no gastan nada del cupo de tu cliente.
El orden
1 · leé el error completo gratis — y casi siempre dice qué paso falta
2 · verificá el objeto gratis — POST /properties/verify
3 · leé lo que tenemos guardado gratis — GET /properties/{paId}
4 · preguntale al portal cuesta 1 llamada
5 · escribinos con la referencia del paso 1
1 · El error completo, no sólo el código
Nuestros errores están escritos para que digan qué hacer, no sólo que algo falló. Además del código traen una descripción y, cuando corresponde, el nombre del campo o del portal.
Lo más importante: un error de los nuestros te dice si el problema es tuyo (algo en lo que mandaste) o del paso anterior (falta la ficha, falta la conexión). Si dice que falta conectar la cuenta, no es un problema de permisos de tu token.
2 · Verificar el objeto (gratis)
POST /properties/verify con el mismo objeto que te falló.
Te dice, portal por portal, qué falta. No le pregunta nada al portal, así que no gasta cupo ni
depende de que el portal esté arriba.
Separa dos cosas que conviene no mezclar:
- Lo que falta en el objeto → está en tu control.
- Lo que falta de la cuenta (el plan, la sucursal) → sale de la conexión, no de la propiedad.
3 · Lo que tenemos guardado (gratis)
GET /properties/{paId} te muestra lo que registramos: si
la propiedad existe, qué portales tiene, y qué pasó en el último intento de publicación.
Es el paso que contesta "¿llegó mi llamada?" sin gastar nada.
4 · Preguntarle al portal (1 llamada)
GET …/publication/{portal} es lo único que sabe si el
aviso está online ahora y cuál es su URL.
Dejalo para el final: es lo único que cuesta, y los tres pasos anteriores suelen explicar el problema sin él.
Los casos que más aparecen
| Lo que ves | Por dónde empezar |
|---|---|
| "Publiqué y no veo el aviso" | El portal puede tardar en mostrarlo. El paso 4 te dice si él ya lo tiene; si dice que sí, es tiempo de publicación del portal, no un problema de la integración |
| El plan que pedí no está disponible | La respuesta del publish te dice cuáles sí tiene tu cliente. Si no esperabas eso, refrescá los planes contra el portal: pudo haber consumido o vencido alguno |
Un 403 | Mirá qué scope dice que falta. Si nombra un portal, tu token no está habilitado para ese portal — es distinto de no poder leer o escribir |
| Dice que la cuenta no está conectada | Pedí la ficha del cliente (gratis) y mirá el estado de sus conexiones. Puede que tu cliente la haya desconectado del lado del portal |
| Una lista de consultas vacía | Antes de asumir que no hay, chequeá qué modo soporta ese portal: puede que ahí las consultas no se pidan, sino que lleguen solas |
| Un dato que mandaste no aparece | Verificá (paso 2): si el portal no soporta ese campo, te lo decimos ahí en vez de descartarlo en silencio |
Lo que conviene descartar antes de escribirnos
- ¿Verificaste el objeto? Es gratis y contesta la mayoría.
- ¿El error nombra un paso anterior (ficha, conexión)? Entonces el problema no está donde estás mirando.
- ¿Estás usando el identificador que te devolvimos, y no uno tuyo, donde la ruta pide el nuestro?
- ¿El portal soporta eso? No todos soportan todo, y lo que no, lo decimos sin gastar cupo.
5 · Escribinos
dev@mapaprop.com. Lo que más acelera la respuesta:
- La referencia que vino en el error. Con eso encontramos tu llamada exacta en nuestros registros — es la diferencia entre mirar el caso y pedirte que lo reproduzcas.
- Qué esperabas y qué pasó, en ese orden.
- El
clientRefy el identificador de la propiedad.
No nos mandes tu token ni la credencial de tu cliente. No los necesitamos para diagnosticar, y si los mandaste por error, decinos para que te ayudemos a rotarlos.
Relacionado
- Buenas prácticas — los flujos completos
- Verificar — el paso 2, el más rentable
- Publicación — qué soporta cada portal