v1 · 14 endpoints · instantreply.up.railway.app
WhatsApp + Instagram
REST API, v1.
Bearer auth. Cursor pagination. Idempotency keys. Webhooks assinados. A API que seu time teria construído se tivesse o fim de semana.
Escolha o runtime
import InstantReply from '@instantreply/node'
const ir = new InstantReply({ apiKey: process.env.IR_API_KEY })
for await (const c of ir.conversations.list.autoPaginate({ status: 'active' })) {
if (c.last_message_preview?.includes('refund')) {
await ir.conversations.update(c.id, { tags: ['priority:refund'] })
}
}Superfície v1
Catorze endpoints, um header de auth.
- GET
/v1/conversations - GET
/v1/conversations/:id - PATCH
/v1/conversations/:id - GET
/v1/conversations/:id/messages - POST
/v1/conversations/:id/messages - GET
/v1/contacts - GET
/v1/contacts/:id - PATCH
/v1/contacts/:id - GET
/v1/channels - GET
/v1/analytics/summary - GET
/v1/usage - GET
/v1/webhooks - POST
/v1/webhooks - DELETE
/v1/webhooks/:id
Design
Decisões chatas, de propósito.
- 01
Cursor pagination, sempre
Todo endpoint de lista retorna has_more e next_cursor. Sem registros perdidos sob carga, sem off-by-one.
- 02
Idempotency-Key no POST
Passe um UUID e tente de novo com segurança por 24 horas. Side effects disparam exatamente uma vez.
- 03
X-Request-Id em toda resposta
Cole o ID no suporte e a gente traça a chamada exata, a resposta exata, a chamada downstream exata.
- 04
Erros com forma
Mesmo envelope JSON em toda falha. code, message, doc_url, request_id. Sem null surpresa.
Erros
Um envelope, sempre.
Sem flags de sucesso aninhados. Sem mistura de casing. Sem 200 silencioso na falha. Se a chamada quebrou, o body te diz exatamente qual chamada, o que ela esperava, e onde tão os docs.
// 422 Unprocessable Entity
{
"error": {
"code": "INVALID_PLATFORM",
"message": "Channel 'tiktok' is not yet supported on v1.",
"doc_url": "https://www.instantreply.co/api-docs#errors",
"request_id": "req_8f2a0b1c"
}
}