Integração da API HubSpot para Ferramentas Internas Personalizadas: Guia Node + Python (2026)

Integração da API HubSpot para Ferramentas Internas Personalizadas: Guia Node + Python (2026)

Ainda à procura de uma chave API HubSpot para configurar a sua integração da API HubSpot? Pare de procurar. A HubSpot eliminou as chaves API estáticas a 30 de novembro de 2022, e o atual SDK para Node (@hubspot/api-client, agora na v14) não as aceita de qualquer forma. A credencial correta para uma ferramenta interna de conta única é um token de acesso de aplicação privada, e este guia constrói uma sincronização real entre a HubSpot e uma ferramenta interna, tanto em Node como em Python, desde a sua primeira chamada create contact até um webhook validado por assinatura.

Resposta rápida: Uma integração da API HubSpot permite que uma ferramenta interna personalizada leia e escreva dados do CRM através da API REST v3 da HubSpot. Para uma ferramenta interna de conta única, autentique-se com um token de acesso de aplicação privada (a HubSpot descontinuou as chaves API em 2022) e sincronize as alterações em tempo real com webhooks em vez de fazer polling.

Eis o que vai construir:

• Autenticação por token de aplicação privada mais a sua primeira chamada create contact em Node e Python
• Um recetor de webhook que valida o X-HubSpot-Signature-v3 antes de confiar num payload
• Uma sincronização segura contra erros 429, em lotes de 100, para um sistema interno de tickets ou ERP

Como Funciona a Integração da API HubSpot para Ferramentas Internas Personalizadas?

Uma integração da API HubSpot conecta uma ferramenta interna personalizada (uma aplicação de tickets, um ERP, um painel de faturação, um portal de cliente) ao CRM da HubSpot através da sua API REST v3. A sua ferramenta lê e escreve objetos do CRM (contactos, negócios, empresas ou objetos personalizados) via HTTPS com um token de acesso de aplicação privada, e as alterações em tempo real fluem de volta através de webhooks.

Pense no CRM da HubSpot como uma base de dados com a qual comunica via HTTP. Cada registo é um objeto com um tipo e um ID. A hubspot crm api integration que está a construir faz duas tarefas: envia dados para a HubSpot (criar um contacto quando um ticket é aberto) e extrai dados dela (ler um negócio quando o seu painel interno é renderizado).

A sincronização ocorre numa de duas direções. Uma sincronização unidirecional copia alterações da HubSpot para a sua ferramenta, ou da sua ferramenta para a HubSpot. Uma sincronização bidirecional faz ambas as coisas e necessita de proteção contra loops, que abordaremos mais adiante. E em vez de perguntar à HubSpot "há algo novo?" a cada minuto (polling), regista um webhook para que a HubSpot lhe informe instantaneamente quando um registo é alterado.

Se preferir ter controlo total sobre os seus dados em vez de integrar um CRM alojado, alojar por conta própria um CRM de código aberto é um caminho diferente que vale a pena ponderar antes de se comprometer. Mas se a HubSpot já é a sua fonte de verdade, a API é a forma como tudo o resto comunica com ela.

Para uma ferramenta interna de conta única, não precisa de OAuth nem de listagem no marketplace de aplicações. Um token de aplicação privada e um webhook constituem toda a integração.

Autenticação em 2026: Por Que Já Não Existe Chave API HubSpot

Para a autenticação da API HubSpot numa ferramenta interna de conta única, utilize um token de acesso de aplicação privada. É um token bearer estático que gera uma vez na sua conta HubSpot, com âmbito limitado exatamente aos objetos que a sua ferramenta utiliza. Não existe fluxo de atualização (refresh) nem expiração. O OAuth existe para aplicações públicas e multi-conta, não para o painel que a sua equipa de operações utiliza internamente.

Token de Aplicação Privada vs a Chave API Descontinuada

Eis a armadilha que apanha metade dos programadores que chegam a esta página de resultados. A HubSpot descontinuou as chaves API a 30 de novembro de 2022, e elas são totalmente não suportadas atualmente. O preenchimento automático ainda sugere "hubspot api key" porque a memória muscular não se adaptou, mas não há nenhuma chave para obter. Opte por uma app privada hubspot: crie-a nas Definições, conceda os âmbitos necessários e copie o token de acesso a partir do separador Auth. A visão geral das aplicações privadas da HubSpot cobre a configuração.

Duas regras sobre o próprio token. Conceda o privilégio mínimo: se a sua ferramenta apenas lê negócios e escreve contactos, solicite crm.objects.contacts.write e crm.objects.deals.read, nada mais. E mantenha o token numa variável de ambiente ou num gestor de segredos, enviado no cabeçalho Authorization: Bearer, nunca codificado diretamente e nunca enviado para o navegador.

O veredicto é simples. Para uma ferramenta interna, utilize um token de acesso de aplicação privada. Recorra ao OAuth apenas se isto se tornar posteriormente uma aplicação pública e multi-conta que outras empresas instalem nos seus próprios portais.

A Sua Primeira Chamada à API HubSpot: Criar um Contacto em Node e Python

A chamada inicial canónica é create contact, e os SDKs oficiais tornam-na em poucas linhas. Instale o cliente, inicialize-o com o seu token de aplicação privada proveniente do ambiente, depois crie um contacto e leia um negócio de volta. Este é o mesmo padrão que reutilizará para empresas, tickets e chamadas hubspot custom objects api, mudando apenas o tipo de objeto.

Eis a versão em Node com @hubspot/api-client (v14):

// npm i @hubspot/api-client   (v14.x)
import { Client } from "@hubspot/api-client";

// Private app token from a secret manager or env var, never hard-coded
const hubspot = new Client({ accessToken: process.env.HUBSPOT_PRIVATE_APP_TOKEN });

// Create a contact
const { id } = await hubspot.crm.contacts.basicApi.create({
  properties: {
    email: "[email protected]",
    firstname: "Ada",
    lastname: "Lovelace",
    lifecyclestage: "lead",
  },
  associations: [],
});
console.log("Created contact", id);

// Read a deal by ID
const deal = await hubspot.crm.deals.basicApi.getById(
  "1234567890",
  ["dealname", "amount", "dealstage"],
);
console.log(deal.properties.dealname, deal.properties.amount);

E o mesmo em Python com hubspot-api-client (v12):

# pip install hubspot-api-client   (v12.x)
import os
from hubspot import HubSpot
from hubspot.crm.contacts import SimplePublicObjectInputForCreate

# Private app token from the environment, not source control
client = HubSpot(access_token=os.environ["HUBSPOT_PRIVATE_APP_TOKEN"])

# Create a contact
contact = client.crm.contacts.basic_api.create(
    simple_public_object_input_for_create=SimplePublicObjectInputForCreate(
        properties={
            "email": "[email protected]",
            "firstname": "Ada",
            "lastname": "Lovelace",
            "lifecyclestage": "lead",
        }
    )
)
print("Created contact", contact.id)

# Read a deal by ID
deal = client.crm.deals.basic_api.get_by_id(
    deal_id="1234567890",
    properties=["dealname", "amount", "dealstage"],
)
print(deal.properties["dealname"], deal.properties["amount"])

Dica profissional: teste num sandbox de desenvolvidor da HubSpot, nunca primeiro em produção. Uma chamada de criação malformada em produção deixa registos reais incorretos que a sua equipa de vendas terá de limpar. O token, os âmbitos e o modelo de objetos comportam-se identicamente no sandbox.

Como Sincronizar a HubSpot com uma Ferramenta Interna em Tempo Real?

Utilize webhooks, não polling. Registe uma subscrição de webhook na sua aplicação privada para o objeto e evento que lhe interessam (digamos, deal.propertyChange), aponte para um endpoint HTTPS que hospeda, e a HubSpot envia-lhe um pequeno array JSON no momento em que ocorre uma alteração correspondente. Faça polling apenas quando não existir subscrição para o que precisa de monitorizar.

A vantagem é a eficiência. O polling pergunta "há algo novo?" a cada minuto e consome o seu limite de taxa a fazê-lo; um webhook apenas informa no momento em que um negócio é alterado. Essa diferença é importante à escala, e os webhooks são agora comuns, não exóticos: o Relatório Estado da API de 2025 da Postman, um inquérito a mais de 5.700 programadores, descobriu que cerca de metade das equipas depende deles.

Registe a subscrição no separador Webhooks da sua aplicação privada, defina o URL de destino e escolha os eventos. A HubSpot envia um array de objetos de evento, cada um contendo o subscriptionType, o objectId e o que foi alterado. Eis um esboço de recetor em Node com Express:

import express from "express";

const app = express();
// Capture the raw body: you need the exact bytes to validate the signature next
app.use(express.json({
  verify: (req, _res, buf) => { req.rawBody = buf.toString("utf8"); },
}));

// HubSpot POSTs an array of events to this URL
app.post("/webhooks/hubspot", (req, res) => {
  const events = req.body; // [{ subscriptionType: "deal.propertyChange", objectId: 1234, ... }]
  for (const event of events) {
    console.log("HubSpot event:", event.subscriptionType, event.objectId);
    // Do NOT trust this payload yet. The next section validates it before we act.
  }
  res.sendStatus(200);
});

app.listen(3000, () => console.log("Listening on :3000"));

É aqui que a construção prática se torna real. Digamos que está a sincronizar um negócio com um registo ERP de um pequeno fabricante: o webhook dispara, o seu handler cria ou atualiza o ticket ERP correspondente, e a sua equipa de operações vê a alteração sem tocar na HubSpot. É a mesma abordagem em tempo real que usamos para sincronizar um agente de voz com um CRM, apenas o gatilho é uma alteração de propriedade em vez de uma chamada telefónica. Um aviso: aquele esboço acima confia em qualquer coisa enviada via POST. Corrija isso antes de colocar em produção.

Validar Assinaturas de Webhook (v3) Para Nunca Confiar num Payload Falsificado

Valide cada webhook recebido com a assinatura v3. A HubSpot assina cada pedido com o segredo da sua aplicação e envia dois cabeçalhos, X-HubSpot-Signature-v3 e X-HubSpot-Request-Timestamp. Rejeite qualquer coisa anterior a 5 minutos, reconstrua a string de origem como método + URL completo + corpo bruto + timestamp, aplique HMAC-SHA256 com o segredo da aplicação, codifique em base64 e compare em tempo constante.

Se ignorar isto, qualquer pessoa que adivinhe o URL do seu webhook pode forjar uma atualização de negócio. A validação não é opcional. A documentação de validação de pedidos da HubSpot e o changelog das assinaturas v3 detalham a receita exata. Eis como middleware Express pronto a usar:

import crypto from "crypto";

const CLIENT_SECRET = process.env.HUBSPOT_APP_SECRET; // from your private app settings
const MAX_AGE_MS = 5 * 60 * 1000; // reject anything older than 5 minutes

export function validateHubSpotSignature(req, res, next) {
  const signature = req.header("X-HubSpot-Signature-v3");
  const timestamp = req.header("X-HubSpot-Request-Timestamp");

  // 1. Reject stale requests (replay protection)
  if (!signature || !timestamp || Date.now() - Number(timestamp) > MAX_AGE_MS) {
    return res.sendStatus(401);
  }

  // 2. Rebuild the exact source string: method + full URL + raw body + timestamp
  const uri = `https://${req.get("host")}${req.originalUrl}`;
  const source = `${req.method}${uri}${req.rawBody}${timestamp}`;

  // 3. HMAC-SHA256 with the app secret, base64-encoded
  const hash = crypto
    .createHmac("sha256", CLIENT_SECRET)
    .update(source, "utf8")
    .digest("base64");

  // 4. Constant-time compare against the header
  const expected = Buffer.from(hash);
  const received = Buffer.from(signature);
  if (expected.length !== received.length ||
      !crypto.timingSafeEqual(expected, received)) {
    return res.sendStatus(401);
  }
  next();
}

A mesma verificação como função Python, para cobrir ambas as stacks:

import base64
import hashlib
import hmac
import os
import time

CLIENT_SECRET = os.environ["HUBSPOT_APP_SECRET"].encode("utf-8")
MAX_AGE_MS = 5 * 60 * 1000  # 5 minutes

def is_valid_signature(method, uri, body, signature, timestamp):
    # 1. Reject stale requests
    if not signature or not timestamp:
        return False
    if int(time.time() * 1000) - int(timestamp) > MAX_AGE_MS:
        return False

    # 2. method + full URL + raw body + timestamp
    source = f"{method}{uri}{body}{timestamp}".encode("utf-8")

    # 3. HMAC-SHA256, base64
    digest = hmac.new(CLIENT_SECRET, source, hashlib.sha256).digest()
    expected = base64.b64encode(digest).decode("utf-8")

    # 4. Constant-time compare
    return hmac.compare_digest(expected, signature)

A armadilha que custa uma tarde às pessoas: a HubSpot assina o URL de destino completo, esquema, host e caminho juntos. Por trás de um proxy, um balanceador de carga ou um túnel ngrok, req.get("host") pode reportar o host interno em vez do público que a HubSpot assinou. Se a validação continuar a falhar num payload que tem certeza ser legítimo, registe o URI exato que reconstruiu e compare-o com o URL público do seu webhook, caractere por caractere.

Limites de Taxa, Erros 429 e a Batch API: O Que Executámos em Produção

As aplicações privadas recebem aproximadamente 10 pedidos por segundo (100 por 10 segundos no plano Free/Starter, 190 por 10 segundos no Pro/Enterprise) com um limite diário entre 250.000 e 1.000.000. A armadilha: a Pesquisa CRM tem um limite separado de 4 pedidos por segundo, e os endpoints de lote aceitam um máximo de 100 registos por pedido. As diretrizes de utilização da HubSpot listam os níveis.

Foi aqui que a teoria encontrou um painel de staging vermelho. Durante um preenchimento retroativo esta primavera, enviámos cerca de 8.000 registos existentes para a HubSpot a partir de uma ferramenta interna de tickets e enriquecemos cada um com uma pesquisa CRM. Estávamos a executar @hubspot/api-client v14 no lado Node e hubspot-api-client v12 para um worker de enriquecimento em Python. As escritas em massa correram bem. As chamadas de Pesquisa falharam dentro de um minuto, porque o nosso worker estava a disparar Pesquisas a cerca de 15 req/s contra um teto rígido de 4 req/s para o qual não tínhamos orçamentado separadamente.

Duas alterações resolveram o problema. Primeiro, um wrapper de retry que lê os cabeçalhos de resposta X-HubSpot-RateLimit-* e recua num erro 429:

// Wrap any HubSpot call; retries on 429 with exponential backoff
async function withRetry(fn, maxRetries = 5) {
  let attempt = 0;
  while (true) {
    try {
      return await fn();
    } catch (err) {
      const status = err.code ?? err.response?.status;
      if (status !== 429 || attempt >= maxRetries) throw err;

      // Honor HubSpot's reset window if the header is present
      const headers = err.response?.headers ?? {};
      const resetMs = Number(headers["x-hubspot-ratelimit-interval-milliseconds"]) || 0;
      const backoff = Math.max(resetMs, 2 ** attempt * 500); // 0.5s, 1s, 2s, 4s...

      console.warn(`429 hit, retry ${attempt + 1} in ${backoff}ms`);
      await new Promise((r) => setTimeout(r, backoff));
      attempt++;
    }
  }
}

Segundo, deixámos de escrever registos um a um. O endpoint de lote aceita até 100 registos por POST /crm/v3/objects/{objectType}/batch/create, por isso dividimos o preenchimento retroativo em 80 chamadas de lote em vez de 8.000 POSTs individuais:

// HubSpot batch endpoints accept at most 100 records per request
function chunk(arr, size = 100) {
  const out = [];
  for (let i = 0; i < arr.length; i += size) out.push(arr.slice(i, i + size));
  return out;
}

// POST /crm/v3/objects/contacts/batch/create, chunked to 100 at a time
async function batchCreateContacts(records) {
  for (const group of chunk(records, 100)) {
    const inputs = group.map((r) => ({
      properties: { email: r.email, firstname: r.firstName, lastname: r.lastName },
      associations: [],
    }));
    await withRetry(() => hubspot.crm.contacts.batchApi.create({ inputs }));
    console.log(`Wrote ${group.length} contacts`);
  }
}

Limitar o worker de Pesquisa a 4 req/s e agrupar as escritas transformou uma execução que se afogava em retries numa que terminou silenciosamente. Se se lembrar de um número desta secção, que seja 4: o limite da Pesquisa CRM é o que morde em produção, e é o que todos os artigos resumidos esquecem de mencionar. O antigo teto de lote "10 para contactos", a propósito, desapareceu; o atual é 100 em todos os tipos de objeto.

Ir Bidirecional: Escrever Alterações de Volta na HubSpot Sem Loops Infinitos

Uma sincronização bidirecional escreve alterações de volta na HubSpot a partir da sua ferramenta interna, além de as ler. O perigo é um loop de feedback: a sua escrita de retorno aciona o próprio webhook que disparou o seu handler, que escreve novamente, eternamente. Previna-o com uma chave de idempotência (ignore alterações que já aplicou) e uma flag de origem (ignore eventos recebidos causados pela sua própria ferramenta).

const processed = new Set(); // use Redis or a unique DB constraint in production

async function writeBackToHubSpot(record) {
  // Dedup key: object id + a hash of the change we're about to apply
  const key = `${record.id}:${record.updatedHash}`;
  if (processed.has(key)) return; // already synced this exact change
  processed.add(key);

  await withRetry(() =>
    hubspot.crm.contacts.basicApi.update(record.id, {
      // Tag the source so the resulting webhook is ignored by our own receiver
      // (check for source: "internal-tool" before acting on an inbound event)
      properties: { internal_status: record.status, last_sync_source: "internal-tool" },
    })
  );
}

O padrão é pequeno, mas ignorá-lo é como uma sincronização duplica silenciosamente o seu volume de escrita durante a noite. Assim que os dados estejam limpos em ambas as direções, as equipas frequentemente alimentam-nos a jusante num pipeline AI SDR ou numa camada de reporting. O tutorial de integração HubSpot da Nango é uma referência sólida apenas para Node se quiser uma segunda opinião sobre sincronização bidirecional, embora tenha de portar a ideia de prevenção de loops por si próprio.

Deve Construir Isto Internamente ou Contratar um Parceiro de Integração?

Construa internamente quando a sincronização for pequena, estável e própria: um fluxo unidirecional, um punhado de objetos e um engenheiro que possa absorver as alterações disruptivas da HubSpot, cerca de duas vezes por ano. Contrate um parceiro quando precisar de sincronização bidirecional, modelação de objetos personalizados, ou quando ninguém na equipa puder assumir a manutenção contínua. O fator decisivo raramente é a construção inicial; é quem vigia o sistema daqui a um ano.

Eis uma checklist honesta. Construa você mesmo se: a direção for unidirecional, estiver a sincronizar objetos padrão, tiver um programador que possa hospedar um endpoint de webhook, e alguém notar quando um payload começar a falhar. Tudo acima é o seu blueprint.

Contrate um parceiro se: precisar de sincronização bidirecional com prevenção de loops através de vários objetos, estiver a modelar objetos personalizados com associações tipadas, estiver a ligar múltiplos sistemas (HubSpot mais um ERP mais faturação), ou a pessoa que manteria o sistema já estiver com capacidade máxima. A HubSpot usa versionamento de API baseado em datas com alterações disruptivas apenas cerca de duas vezes por ano, o que parece suave até uma ocorrer durante a sua semana mais ocupada e não haver responsável. Essa cauda de manutenção, não o primeiro deploy, é o que afunda silenciosamente as integrações internas. Se preferir não assumir essa responsabilidade, é aí que os nossos serviços personalizados de integração CRM entram.

Principais Conclusões

• Já não existe chave API HubSpot. Utilize um token de acesso de aplicação privada para uma ferramenta interna de conta única; OAuth é apenas para aplicações públicas e multi-conta.
• Valide sempre o X-HubSpot-Signature-v3 antes de confiar num payload de webhook. Reconstrua a string de origem com o URL de destino completo.
• Respeite o limite de 4 req/s da Pesquisa CRM e agrupe escritas grandes em lotes de 100 com recuo em caso de erro 429.
• Prefira webhooks a polling para sincronização em tempo real, e uma integração HubSpot é uma peça de uma stack mais ampla de ferramentas AI para negócios.

Preso no lado da manutenção, ou quer um segundo par de olhos antes de lançar? Marque uma consulta de integração gratuita. Sem pressão de qualquer forma; o código acima é seu para executar independentemente.

Sobre o Autor

Mert Batur Gurbuz é Co-Fundador da Techsy.io, onde a equipa lança agentes AI, sistemas de automação e pipelines de voz/SDR para clientes B2B. Estuda na Universidade de Birmingham e escreve sobre a stack de ferramentas LLM que a equipa da Techsy realmente utiliza em produção. Credenciais: Co-Fundador, Techsy.io, Universidade de Birmingham. Conecte-se no LinkedIn.

Perguntas Frequentes

Ainda preciso de uma chave API HubSpot em 2026?

Não. A HubSpot descontinuou as chaves API estáticas a 30 de novembro de 2022, e elas são totalmente não suportadas. O preenchimento automático ainda sugere "hubspot api key" por hábito, mas não há nada para obter. Para uma ferramenta interna de conta única, crie uma aplicação privada nas Definições e utilize o seu token de acesso.

Qual é a diferença entre um token de app privada e OAuth para a HubSpot?

Um token de acesso de aplicação privada é uma credencial estática para uma única conta HubSpot, sem expiração e sem fluxo de atualização, ideal para uma ferramenta interna. OAuth 2.0 é para aplicações públicas e multi-conta que outras empresas instalam nos seus próprios portais; os seus tokens expiram em cerca de seis horas e requerem um ciclo de atualização.

Quais são os limites de taxa da API HubSpot em 2026?

As aplicações privadas recebem cerca de 10 pedidos por segundo (100 por 10 segundos no Free/Starter, 190 no Pro/Enterprise) com um limite diário de 250.000 a 1.000.000. A API de Pesquisa CRM tem um limite separado de 4 pedidos por segundo, e os endpoints de lote aceitam um máximo de 100 registos por pedido.

Como valido uma assinatura de webhook HubSpot?

Utilize a receita v3: rejeite pedidos onde X-HubSpot-Request-Timestamp seja anterior a cinco minutos, depois construa uma string de origem com método mais URL de destino completo mais corpo bruto mais timestamp. Aplique HMAC-SHA256 com o segredo da sua aplicação, codifique o resultado em base64 e compare-o com X-HubSpot-Signature-v3 em tempo constante.

Qual SDK HubSpot devo usar, Node ou Python?

Ambos são oficiais e mantidos. Node usa @hubspot/api-client (v14) e Python usa hubspot-api-client (v12). Eles expõem o mesmo modelo de objeto CRM v3, por isso escolha o que corresponder à sua stack. Este guia fornece código idêntico de autenticação e validação de assinatura em ambas as linguagens.

Como sincronizo a HubSpot com uma ferramenta interna personalizada em tempo real?

Registe uma subscrição de webhook na sua aplicação privada para o objeto e evento que lhe interessam, depois hospede um endpoint HTTPS para o qual a HubSpot envia POST quando ocorre uma alteração correspondente. Valide a assinatura, depois escreva a alteração na sua ferramenta interna. Faça polling apenas quando nenhuma subscrição de webhook cobrir o que precisa.

O que é uma Service Key HubSpot e devo usá-la?

Uma Service Key é uma credencial apenas de dados, a nível de conta, que a HubSpot colocou em beta público em fevereiro de 2026. Destina-se a tarefas do lado do servidor que apenas tocam em dados. Para uma ferramenta interna padrão hoje, um token de acesso de aplicação privada continua a ser o padrão mais seguro e melhor documentado; trate as Service Keys como beta até que sejam graduadas.

Posso testar uma integração HubSpot sem tocar na produção?

Sim. Crie um sandbox de desenvolvedor HubSpot e aponte o seu token de aplicação privada para ele. Os âmbitos, modelo de objeto, webhooks e limites de taxa comportam-se da mesma forma que na produção, por isso pode criar contactos de teste e disparar webhooks sem deixar registos incorretos para a sua equipa de vendas limpar mais tarde.

Quantos registos a batch API HubSpot pode aceitar de uma vez?

Os endpoints de lote (POST /crm/v3/objects/{objectType}/batch/create e os seus irmãos de atualização e upsert) aceitam um máximo de 100 registos por pedido. Divida payloads maiores em grupos de 100. O antigo teto de "10 registos para contactos" que alguns tutoriais ainda citam foi removido; 100 é o atual em todos os tipos de objeto.

Devo construir isto internamente ou contratar uma agência?

Construa internamente quando a sincronização for unidirecional, usar objetos padrão e tiver um responsável que possa absorver as alterações disruptivas da HubSpot duas vezes por ano. Contrate um parceiro para sincronização bidirecional, modelação de objetos personalizados, ou quando ninguém puder assumir a manutenção. O primeiro deploy é fácil; o ano de manutenção após ele é o custo real.