DEVELOPING

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 vesPor 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á disponibleLa 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 403Mirá 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á conectadaPedí 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íaAntes 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 apareceVerificá (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:

  1. 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.
  2. Qué esperabas y qué pasó, en ese orden.
  3. El clientRef y 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