Pular para o conteúdo principal
A API de pedidos v2 cobre todos os produtos físicos e híbridos. O campo shipType seleciona o produto e determina quais campos são obrigatórios.

​
Tipos de envio

Sedex (shipType 6 e 7) só sai de Jaú/SP. Ou você envia virtualbox=1, que substitui o remetente pela unidade da Escrybe, ou usa um endereço de remetente em Jaú/SP. Qualquer outra cidade de remetente é recusada com 400.

​
Endpoints

Os schemas completos de requisição/resposta estão na aba Referência da API.

​
Faturar em um time

paymentMethod=team fatura o pedido ao responsável de um time de que você participa (em vez dos seus créditos ou da sua fatura). Ele exige team_member_id, e esse número não é o ID do time: é o ID da sua participação naquele time, diferente para cada membro. Dois jeitos de obtê-lo:
  • GET /api/v2/teams/{securityToken} lista os times em que você pode faturar, cada um com o seu team_member_id. A lista é a mesma do grupo “Times” da forma de pagamento nas telas de envio do painel: só participações ativas e só times cujo responsável tem um plano que permite faturamento.
  • No painel, em Times, cada time mostra “ID para a API” com um botão de copiar.
O dono do time também aparece na lista (you_are_owner: true) e fatura no próprio time com o seu team_member_id. Um team_member_id que não seja uma participação sua responde 403; um time cujo responsável não pode faturar responde 400. O mesmo campo vale para /api/email/v1/post e /api/whatsapp/v1/post.

​
Enviando o documento

O campo pdfFile aceita três formas:
  • Base64 — uma string PDF codificada em base64
  • URL — uma URL pública (buscada no servidor via proxy); links públicos de Google Docs/Drive são suportados
  • Upload de arquivo — uma parte de arquivo multipart/form-data
PDFs devem ter ≤ 20 MB (≤ 4 MB quando baixados de uma URL), ≤ 150 páginas e não podem ter senha. Um arquivo maior é recusado com 400 em qualquer forma de envio.
Sempre faça uma requisição test=1 primeiro para validar o endereço, a contagem de páginas e o preço sem debitar créditos.

​
Telegramas & e-Carta

Esses produtos levam um corpo de texto em vez de um PDF (o conteúdo renderizado é limitado a 10 páginas):
  • shipType=4 exige telegram_msg (mín. 10 caracteres) e as flags telegram_post_dated, telegram_sender_copy e telegram_delivery_confirmation (cada uma deve estar presente com valor 0 ou 1). Quando telegram_post_dated=1, telegram_post_dated_date deve ser uma data futura.
  • Os campos opcionais telegram_sender_copy_format e telegram_delivery_confirmation_format escolhem como cada adicional chega: physical (papel, pelo correio), electronic (e-mail dos Correios para o e-mail da conta) ou both (ambos, o padrão). telegram_additional_email troca o e-mail da conta na via eletrônica; endereço mal formatado devolve 400.
  • Cada adicional postado em papel é um objeto próprio dos Correios, com código de rastreio próprio. O GET /api/v2/get devolve-os em telegram_info (tracking_pc, tracking_cc) com a linha do tempo dos Correios e o estado derivado (tracking_pc_records, tracking_pc_state, …), atualizados de hora em hora. O status e o status_delivery do telegrama não mudam por causa deles.
  • Na via eletrônica, o PDF que os Correios mandam por e-mail é anexado ao pedido automaticamente (até 15 minutos depois de chegar): a cópia ao remetente vira sender_copy_available = true e a confirmação de entrega entra em files como rr_electronic, com o webhook rr.created.
  • shipType=8|9|10 exigem ecarta_msg (mín. 10 caracteres, pode conter HTML).

​
Baixando arquivos

/api/v2/download/{securityToken}/{job_id}/{type} retorna o conteúdo em base64. O parâmetro type seleciona o arquivo: