Como Proteger e Governar APIs no SAP BTP com o API Management

Para quem é este guia: desenvolvedores e arquitetos SAP (ABAP/RAP, CPI, BTP) que já expõem serviços OData/REST e querem colocá-los atrás de uma camada de gestão profissional — com segurança, controle de tráfego, transformação e governança de ciclo de vida. Foco no SAP API Management, capacidade do SAP Integration Suite no BTP.

Por que uma camada de API Management?

Porque, sem ela, cada consumidor precisa reinventar segurança, throttling e tratamento de erro — e ninguém faz isso de forma consistente. O API Management centraliza esses aspectos como uma fachada entre consumidores e backends. A SAP resume o valor em cinco funções clássicas [SAP Insider — Dynamic API Management]:

Repare que o gateway não é o dono da regra de negócio — ele é a camada onde segurança, tráfego e forma da mensagem viram responsabilidade de plataforma, não de cada API. Essa separação é o que torna o conjunto governável SAP Community — Policy Management

Diferencial 2026: o API Management do BTP agora inclui gestão de ciclo de vida de MCP servers — expor APIs curadas como MCP servers governados para agentes de IA — e detecção de anomalias de API em tempo real. A mesma fachada que protege consumidores humanos passa a governar o consumo por agentes.

Arquitetura: os quatro blocos fundamentais

Antes de qualquer policy, entenda os quatro artefatos que estruturam tudo: API Provider, API Proxy, API Product e Application. Eles formam uma cadeia — do backend até quem consome a API key — e cada um tem um papel exclusivo.

Diagrama 1 — Os quatro blocos do SAP API Management

API Provider

Abstrai a conexão ao backend (sistema S/4HANA on-prem via Cloud Connector, sistema na internet, CPI iFlow etc.). É onde você define host, porta, tipo (On-Premise / Internet) e a autenticação usada para carregar o catálogo de serviços SAP-PRESS — Complete Guide. Para on-premise, o Cloud Connector precisa expor o backend no subaccount.

API Proxy

É a API que você realmente publica — o intermediário entre consumidor e backend, onde toda a lógica (as policies) roda na camada do API Management, não no backend. Pode expor REST, OData e SOAP. Um proxy tem dois tipos de endpoint:

• Proxy Endpoint — conexões de entrada (inbound). Define como os consumidores chamam a API. Obrigatório (sempre há um).

• Target Endpoint — conexões de saída (outbound) para o backend. Pode haver zero ou muitos, e uma Route Rule condicional decide qual target chamar (ex.: proxy.pathsuffix MatchesPath "/latest").

API Product

Agrupa um ou mais API Proxies em um pacote publicável no developer portal (Developer Hub / API Business Hub Enterprise). É a unidade de subscription — o consumidor assina o produto, não o proxy diretamente.

Application (Consumidor)

Ao assinar um produto, o desenvolvedor cria uma Application e recebe Application Key + Secret. A Application Key é a API Key usada nas chamadas.

O pipeline de processamento: Flows

Toda requisição atravessa um pipeline de quatro pontos de execução. Entender isso é o que separa quem "arrasta policies aleatoriamente" de quem projeta o gateway corretamente.

Diagrama 2 — O pipeline de uma requisição (segurança cedo, transformação tarde)

• Proxy PreFlow (request): o lugar das validações de entrada — método HTTP, IP allowlist, OAuth/API Key, Spike Arrest, Quota, threat protection.

• Target PreFlow (request): preparar a request para o backend — Assign Message para reescrever target.url, headers, service callouts.

• Target PostFlow (response): tratar a resposta do backend — mapeamento de erros, scripts.

• Proxy PostFlow (response): transformar/mascarar/filtrar a resposta antes de entregar ao consumidor.

Regra de posicionamento: segurança e throttling o mais cedo possível (Proxy PreFlow) para rejeitar tráfego ruim antes de gastar recursos; transformação de payload o mais tarde possível (PostFlow) para trabalhar sobre o dado final.

Flow Variables: o "buffer" que amarra tudo

Antes das policies, entenda as flow variables — o estado compartilhado que trafega pelo pipeline. Toda policy lê e escreve variáveis; dominar isso é o que permite compor policies com segurança (o análogo do "buffer transacional" do RAP, mas para o gateway).

Em condições de fluxo/route rule, você combina essas variáveis — (request.verb = "POST") and (proxy.pathsuffix MatchesPath "/orders"). Em JavaScript/Python, acessa via context.getVariable(...) / context.setVariable(...). Manter as policies comunicando-se por variáveis (em vez de reprocessar o payload várias vezes) é a base de um pipeline íntegro e previsível.

As policies: catálogo e as 4 categorias

O API Management traz mais de 40 policies prontas, classificadas em quatro categorias. Uma policy é um programa que executa uma função específica em runtime, aplicável ao stream de request ou response e ao proxy ou target endpoint — sem você codificar do zero toda vez.

Como ler as seções seguintes: cada policy é descrita no mesmo padrão — o que é · quando usar · quando NÃO usar · exemplo · nota de integridade. Assim você sabe não só como configurar, mas quando cada uma é a escolha certa (e quando é a errada).

Segurança na prática

Verify API Key

O que é: valida a Application Key enviada pelo consumidor. A enforcement acontece no nível do API Proxy, não do produto — todo proxy precisa validar a chave explicitamente.

Quando usar

• APIs internas/parceiros onde a identidade do app basta (não há usuário final).

• Como identificador para Quota por aplicação (a chave resolve client_id).

• Cenários simples de "No Auth + API key", onde o backend não exige credencial própria.

Quando NÃO usar

• APIs públicas expostas a apps de terceiros não confiáveis → use OAuth (a chave viaja em texto e não expira).

• Quando é preciso identidade de usuário final e escopos → OAuth/SAML.

• Como única proteção de dados sensíveis → combine com TLS + threat protection + rate limit.

<!-- Verify API Key — Proxy PreFlow (request) -->
<VerifyAPIKey async="false" continueOnError="false" enabled="true">
  <APIKey ref="request.header.x-api-key"/>
</VerifyAPIKey>

GET https://<host>/s4/business-partners
x-api-key: <application key gerada na subscription>

Sem a chave (ou inválida) → invalid API key; sempre faça o teste negativo.

Integridade: coloque no início do Proxy PreFlow com continueOnError="false" — rejeita a requisição antes de qualquer transformação ou chamada ao backend, evitando processamento de tráfego não autenticado.

OAuth 2.0 (Client Credentials)

O que é: autenticação via token de acesso. O SAP API Management suporta o grant Client Credentials para A2A.

Quando usar

• Integrações máquina-a-máquina (CPI, apps externos, jobs) que exigem credencial que expira.

• Quando você quer revogação e rotação de credenciais sem trocar a chave em todos os consumidores.

• APIs expostas para fora do perímetro corporativo.

Quando NÃO usar

• Protótipos internos de baixo risco onde a API Key já resolve (evita complexidade do fluxo de token).

• Quando o backend já faz a validação de token e você só precisa de passthrough (não duplique).

# 1) Obter o token
POST https://<host>/oauth2/token
Authorization: Basic base64(<key>:<secret>)
Content-Type: application/x-www-form-urlencoded

grant_type=client_credentials      # → { "access_token": "...", "expires_in": 3600 }

# 2) Chamar a API com o token
GET https://<host>/s4/business-partners
Authorization: Bearer <access_token>

<!-- Verificar o token — Proxy PreFlow -->
<OAuthV2 async="false" continueOnError="false" enabled="true">
  <Operation>VerifyAccessToken</Operation>
</OAuthV2>

Expiração padrão de 1h (3600s), configurável.

Integridade: token expirado/inválido é barrado no gateway, poupando o backend. Combine com Quota por client_id para que cada consumidor respeite seu limite contratual, garantindo isolamento entre tenants.

Access Control (allowlist/denylist de IP)

O que é: permite/bloqueia requisições por faixa de IP de origem.

Quando usar

• APIs que só devem ser chamadas de redes corporativas conhecidas ou de um parceiro específico.

• Camada extra de defesa em profundidade sobre autenticação.

Quando NÃO usar

• Consumidores com IP dinâmico/móvel → vira fonte de falsos negativos.

• Como único controle (IP pode ser spoofado atrás de proxies) → sempre junto de auth.

<!-- Proxy PreFlow — permitir apenas faixa corporativa -->
<AccessControl async="false" continueOnError="false" enabled="true">
  <IPRules noRuleMatchAction="DENY">
    <MatchRule action="ALLOW">
      <SourceAddress mask="24">10.20.30.0</SourceAddress>
    </MatchRule>
  </IPRules>
</AccessControl>

Integridade: noRuleMatchAction="DENY" garante postura default-deny — só passa o que foi explicitamente permitido.

Threat Protection (JSON/XML/Regex)

O que é: valida a estrutura do payload para barrar ataques de injeção e payloads absurdamente grandes (DoS via profundidade/tamanho).

Quando usar

• Sempre em endpoints que aceitam corpo (POST/PATCH), especialmente expostos externamente.

• JSON Threat Protection para REST/OData; XML Threat Protection para SOAP; Regular Expression Protection contra SQL injection.

Quando NÃO usar

• Em endpoints puramente de leitura (GET sem corpo) — sem efeito útil, só overhead.

• Com limites tão apertados que rejeitem payloads legítimos — dimensione pelos dados reais.

<!-- Proxy PreFlow — limitar profundidade/tamanho do JSON -->
<JSONThreatProtection async="false" continueOnError="false" enabled="true">
  <ArrayElementCount>100</ArrayElementCount>
  <ContainerDepth>10</ContainerDepth>
  <ObjectEntryCount>50</ObjectEntryCount>
  <StringValueLength>2000</StringValueLength>
</JSONThreatProtection>

Integridade: rode antes de qualquer parsing/transformação (Extract Variables, JS). Assim um payload malicioso nunca chega à lógica que o interpreta — protege tanto o gateway quanto o backend.

Controle de tráfego

Spike Arrest vs. Quota — a distinção que mais confunde

Spike Arrest — quando usar: proteger o backend de rajadas súbitas (retries em loop, cliente mal-comportado). Quando NÃO usar: como limite de plano/contrato (isso é Quota) — ele não conta volume acumulado, só espaçamento entre chamadas.

<!-- Spike Arrest — Proxy PreFlow — protege contra rajadas -->
<SpikeArrest async="false" continueOnError="false" enabled="true">
  <Rate>30ps</Rate>   <!-- 30 por segundo; use 'pm' para por minuto -->
</SpikeArrest>

Quota — quando usar: impor o limite do plano por consumidor (client_id), monetização, fair-use. Quando NÃO usar: para conter rajadas de curtíssimo prazo (isso é Spike Arrest).

<!-- Quota — Proxy PreFlow — POST "pesa" 2x um GET (MessageWeight) -->
<Quota async="false" continueOnError="false" enabled="true" type="calendar">
  <StartTime>2026-01-01 00:00:00</StartTime>   <!-- obrigatório no type=calendar (UTC) -->
  <Allow count="10000"/>
  <Interval>1</Interval>
  <TimeUnit>day</TimeUnit>
  <Identifier ref="client_id"/>                <!-- quota POR consumidor -->
  <MessageWeight ref="request.header.weight"/> <!-- pondera custo por chamada -->
  <Distributed>true</Distributed>
  <Synchronous>true</Synchronous>
</Quota>

O MessageWeight permite contar operações caras (ex.: POST) como múltiplas unidades — pode vir de header, query param ou payload.

Integridade: Distributed="true" + Synchronous="true" garantem uma contagem consistente entre os nós do gateway — sem isso, dois nós poderiam contar em paralelo e deixar passar mais que o limite. Para OData $batch, a SAP recomenda Quota + JavaScript contando as operações dentro do batch, senão um batch com 100 operações contaria como 1.

Concurrent Rate Limit

O que é: limita o número de conexões simultâneas ao target (não a taxa, mas a concorrência).

Quando usar: backend com pool de conexões limitado (ex.: sistema on-prem que aguenta poucas sessões paralelas). Quando NÃO usar: quando o problema é volume/rajada (use Quota/Spike Arrest) — concorrência é outra dimensão.

Integridade: protege o backend de exaustão de recursos (esgotar work processes/sessões no S/4HANA), preservando a disponibilidade para todos os consumidores.

Response Cache / Lookup + Populate Cache

O que é: o Response Cache cacheia a resposta inteira por chave; Lookup/Populate/Invalidate Cache dão controle granular (guardar/ler valores específicos, ex.: um token ou tabela de-para).

Quando usar

• Leituras idempotentes e estáveis de alto volume (catálogos, listas de moedas, dados mestres pouco mutáveis).

• Cachear um token de serviço externo obtido via Service Callout para não re-autenticar a cada chamada.

Quando NÃO usar

• Dados transacionais/voláteis (saldo, estoque, status de pedido) → risco de servir dado velho.

• Respostas personalizadas por usuário sem incluir a identidade na CacheKey → vazamento entre consumidores.

<!-- Response Cache — leituras frequentes; chave inclui URI -->
<ResponseCache async="false" continueOnError="false" enabled="true">
  <CacheKey><KeyFragment ref="request.uri" type="string"/></CacheKey>
  <ExpirySettings><TimeoutInSec>300</TimeoutInSec></ExpirySettings>
</ResponseCache>

Com Lookup Cache, a variável lookupcache.{policy}.cachehit indica se houve acerto — use-a em condição para pular a chamada ao backend.

Integridade: a chave de cache define a corretude. Inclua tudo que diferencia a resposta (URI, query params relevantes, e a identidade se a resposta for personalizada). Um TimeoutInSec curto reduz a janela de dado obsoleto; para dados que mudam por evento, prefira Invalidate Cache após a escrita.

Mediação e transformação

Assign Message

O que é: cria/altera variáveis, headers, query params e até constrói mensagens — o "canivete" da mediação. Uso clássico: reescrever target.url para rotear a um caminho específico do backend.

Quando usar: ajustar roteamento, injetar headers técnicos (correlation-id), normalizar a request antes do backend. Quando NÃO usar: lógica condicional complexa (vários if) → use JavaScript; regra de negócio → backend.

<!-- Target PreFlow (currencies-endpoint) -->
<AssignMessage async="false" continueOnError="false" enabled="true">
  <AssignVariable>
    <Name>target.url</Name>
    <Value>https://backend.host/api/currencies/all</Value>
  </AssignVariable>
  <Add><Headers><Header name="X-Correlation-Id">{messageid}</Header></Headers></Add>
</AssignMessage>

Integridade: um correlation-id propagado do gateway ao backend permite rastrear uma requisição ponta a ponta — essencial para auditar e reconciliar dados em caso de falha parcial.

Extract Variables

O que é: extrai valores de headers, query params ou do payload (JSONPath/XPath) para variáveis reutilizáveis no fluxo.

Quando usar: capturar um campo do corpo (ex.: orderId) para usar em roteamento, logging ou validação. Quando NÃO usar: para ler algo que já está numa flow variable pronta (ex.: client_id) — não reprocessar o payload à toa.

<!-- Extrair orderId do JSON de entrada -->
<ExtractVariables async="false" continueOnError="false" enabled="true">
  <Source>request</Source>
  <JSONPayload>
    <Variable name="orderId"><JSONPath>$.order.id</JSONPath></Variable>
  </JSONPayload>
</ExtractVariables>

Integridade: extrair uma vez e reusar a variável evita divergir a interpretação do payload entre policies — uma única "fonte da verdade" para aquele valor no pipeline.

Data Masking (JavaScript / XSL Transform)

O que é: oculta dados sensíveis na resposta antes de devolver ao consumidor.

Quando usar: expor um backend que retorna PII/dados financeiros a consumidores que não devem vê-los na íntegra. Quando NÃO usar: quando o correto é não buscar o dado (filtre no backend/CDS) — mascarar no gateway ainda trafega o dado até ali.

// JavaScript — Proxy PostFlow (response): mascara CPF/e-mail
var body = context.getVariable("response.content");
if (body) {
  var obj = JSON.parse(body);
  if (obj.taxNumber) obj.taxNumber = obj.taxNumber.replace(/\d(?=\d{2})/g, "*");
  if (obj.email)     obj.email     = obj.email.replace(/(.{2}).*(@.*)/, "$1***$2");
  context.setVariable("response.content", JSON.stringify(obj));
}

Para XML, a SAP documenta mascaramento via XSL Transform (SAP-samples)

Service Callout

O que é: faz uma chamada HTTP a um serviço auxiliar no meio do fluxo (ex.: buscar um token, enriquecer dados de outra API) sem sair do pipeline.

Quando usar: enriquecer a request com dado de um segundo sistema; obter token OAuth de terceiro (e cachear com Populate Cache). Quando NÃO usar: orquestração pesada de múltiplas chamadas com transformação → isso é trabalho do CPI/iFlow, não do gateway.

Integridade: trate falha do callout explicitamente (Fault Rule) — nunca deixe o fluxo seguir com dado de enriquecimento ausente e gravar algo incompleto no backend.

Message Logging (auditoria)

O que é: registra as interações da API em log externo (syslog), para auditoria e troubleshooting.

Quando usar: trilha de auditoria, correlação de incidentes, compliance. Quando NÃO usar: logar payload sensível completo — registre metadados, nunca PII em claro.

<!-- Registrar metadados de cada interação (audit trail) -->
<MessageLogging async="false" continueOnError="true" enabled="true">
  <Syslog>
    <Message>API={apiproxy.name} client={client_id} status={response.status.code} path={proxy.pathsuffix} corr={messageid}</Message>
  </Syslog>
</MessageLogging>

Integridade: use continueOnError="true" no logging — uma falha ao registrar o log não deve derrubar a transação de negócio. Logue o corr/correlation-id para reconciliar depois.

Tratamento de erros: Fault Rules

Por padrão, ao encontrar um erro o proxy sai do pipeline normal e entra em um error Flow, devolvendo a mensagem/código bruto ao consumidor — ruim para usabilidade. Você customiza isso com Fault Rules, que podem ser anexadas a proxy endpoints, target endpoints e route rules.

<!-- Fault Rule + Raise Fault: padronizar erro de autenticação -->
<FaultRule name="invalid-key">
  <Condition>(fault.name = "InvalidApiKey")</Condition>
  <Step><Name>RF-401</Name></Step>
</FaultRule>

<!-- Policy Raise Fault: RF-401 -->
<RaiseFault async="false" continueOnError="false" enabled="true">
  <FaultResponse>
    <Set>
      <StatusCode>401</StatusCode>
      <ReasonPhrase>Unauthorized</ReasonPhrase>
      <Payload contentType="application/json">
        {"error":"invalid_api_key","message":"Chave de API ausente ou inválida"}
      </Payload>
    </Set>
  </FaultResponse>
</RaiseFault>

Quando usar: sempre — padronizar respostas de erro é requisito de uma API profissional. Quando NÃO usar: para mascarar um erro real deixando o consumidor achar que deu certo (nunca retorne 200 sobre uma falha) — isso corrompe a noção de sucesso/fracasso e leva o cliente a não reprocessar dados que falharam.

Integridade: mapeie os erros do backend para códigos HTTP corretos e mensagens claras, sem vazar stack traces/detalhes internos. Um consumidor que recebe 409 Conflict sabe que precisa reler e reenviar; um que recebe erro genérico pode reenviar cegamente e duplicar dados.

Padrões de integridade de dados no gateway

O gateway não é o dono da regra de negócio (isso é do backend/RAP), mas há quatro padrões em que ele é decisivo para não corromper dados. Estes são os pontos mais importantes quando o assunto é integridade.

Idempotência (evitar duplicação em retries)

Redes falham; clientes reenviam. Sem cuidado, um POST reenviado cria dois pedidos. Padrão: exigir um header Idempotency-Key e, no gateway, detectar repetição via cache.

// JavaScript — Proxy PreFlow: bloquear POST repetido com mesma Idempotency-Key
var key = context.getVariable("request.header.Idempotency-Key");
if (context.getVariable("request.verb") === "POST") {
  if (!key) { context.setVariable("flow.reject", "missing-idem-key"); }
  // 'seen' é populado/lido via Lookup+Populate Cache com CacheKey = key
}

Combine com Lookup Cache (cachehit) para, se a chave já foi vista, não repassar ao backend e devolver a resposta anterior. Quando NÃO usar: em GET/consultas (idempotentes por natureza) — só faz sentido para operações que escrevem.

Integridade: transforma um retry potencialmente destrutivo em uma operação segura — o backend nunca vê a mesma escrita duas vezes.

Concorrência otimista (ETag / If-Match)

Em OData (incluindo Web APIs RAP), a atualização concorrente é controlada por ETag: o cliente envia If-Match com o ETag que leu; se o dado mudou nesse meio-tempo, o backend responde 412 Precondition Failed. O gateway deve repassar esses headers intactos.

// JavaScript — Proxy PreFlow: exigir If-Match em PATCH/PUT
var verb = context.getVariable("request.verb");
if ((verb === "PATCH" || verb === "PUT") &&
    !context.getVariable("request.header.If-Match")) {
  // dispare uma Fault Rule → 428 Precondition Required
  context.setVariable("flow.reject", "missing-if-match");
}

Quando NÃO usar: não gere ETag no gateway — quem detecta o conflito é o backend (o RAP faz isso com o campo de controle de bloqueio/%tky). O papel do gateway é só exigir e transportar o header.

Integridade: garante que duas edições simultâneas não se sobrescrevam silenciosamente — o "lost update" clássico é evitado no nível do protocolo.

Validação de contrato/schema na entrada

Barrar payloads malformados antes do backend evita gravar lixo. Use JSON/XML Threat Protection (estrutura) + JavaScript/Extract Variables (campos obrigatórios) para rejeitar cedo.

// JavaScript — Proxy PreFlow: exigir campos obrigatórios
var b = JSON.parse(context.getVariable("request.content") || "{}");
if (!b.customerId || !b.amount || b.amount <= 0) {
  context.setVariable("flow.reject", "invalid-payload");  // → Fault Rule 400
}

Quando NÃO usar: para regras de negócio profundas (limites de crédito, consistência entre entidades) → isso pertence às validations do RAP, não ao gateway. O gateway valida forma; o backend valida regra.

Integridade: é a mesma filosofia do precheck do RAP, só que uma camada antes — rejeitar o obviamente inválido o mais cedo possível, sem sobrepor a validação autoritativa do backend.

OData $batch e limites

Um único $batch pode conter dezenas de operações de escrita. Sem tratamento, a Quota conta como 1 e o Threat Protection pode não ver o tamanho real.

Quando usar tratamento especial: sempre que o proxy aceitar $batch. Conte as operações via JavaScript e alimente o MessageWeight da Quota; aplique limites de tamanho no batch inteiro. Quando NÃO usar: APIs que não expõem $batch (REST simples) — sem overhead desnecessário.

Integridade: garante que o custo/limite reflita o trabalho real imposto ao backend, evitando que um batch gigante burle a quota e sature o S/4HANA.

Resumo: gateway vs. backend na integridade

Princípio: o gateway protege e mede; o backend decide e persiste. Nunca mova regra de negócio para o gateway nem delegue segurança de tráfego ao backend.

Árvore de decisão: qual policy usar?

Na dúvida sobre qual policy resolve o seu problema, siga a intenção — da pergunta (à esquerda) para a policy certa (à direita):

Diagrama 3 — Qual policy usar? Árvore de decisão da intenção para a policy

Cenário end-to-end: expondo um OData S/4HANA (RAP) via API Management

Amarrando tudo, o fluxo completo para publicar profissionalmente um serviço OData V4 (ex.: um Web API gerado por RAP). Se você ainda vai ativar o serviço no backend, vale revisar antes como ativar uma API OData V4 standard ou o fluxo de OData V2.

Diagrama 4 — Publicar um OData S/4HANA via API Management (8 passos)

1. Cloud Connector — exponha o backend S/4HANA on-prem no subaccount do BTP (verifique em Connectivity > Cloud Connectors que o host aparece em Exposed Backend Systems).

2. API Provider — crie em Configure > APIs > API Providers: Type = On-Premise, host/porta virtuais, autenticação = None ou Principal Propagation; teste a conexão (espere HTTP 200).

3. API Proxy — crie apontando para o API Provider e a URL relativa do serviço OData; Service Type = OData (ou REST), defina o Base Path.

4. Policies — no Proxy PreFlow: Verify API Key (ou OAuth) + Spike Arrest + Quota + JSON Threat Protection; no PostFlow: masking/logging conforme necessário. Deploy o proxy.

5. API Product — em Engage > Products, crie o produto, adicione o proxy e publique.

6. Application/Subscription — no API Business Hub Enterprise / Developer Hub, o consumidor assina o produto e recebe Application Key + Secret.

7. Teste — no Postman, chame a URL do proxy com o header x-api-key (ou Authorization: Bearer). Faça também o teste negativo (sem chave) para confirmar o bloqueio.

8. Debug/Monitor — use o Debug do proxy (Configure > API proxy > Debug) para inspecionar o pipeline, e o dashboard de analytics para tráfego/erros/latência.

Referência de setup inicial: ative Manage APIs + Developer Hub e atribua as roles APIManagement.Selfservice.Administrator e AuthGroup.SelfService.Admin. Quando precisar tirar segredos de dentro do proxy e orquestrar tokens, o combo de [INTERNAL-LINK: Key Value Maps criptografadas + Service Callout → artigo-irmão de API Management] é o próximo passo natural; e para consumo idempotente a partir de integrações, veja o [INTERNAL-LINK: Idempotent Process Call no CPI → artigo-irmão de Integration Suite].

Boas práticas e anti-padrões

Resumo executivo

O SAP API Management transforma serviços OData/REST/SOAP (inclusive Web APIs RAP) em APIs governadas: uma fachada única com segurança consistente (API Key, OAuth, threat protection), controle de tráfego (Spike Arrest, Quota, cache), transformação (Assign Message, JS, XSL) e governança de ciclo de vida (products, developer portal, analytics). O segredo técnico está em dominar o pipeline de flows — colocar cada policy no ponto certo (segurança cedo, transformação tarde) — e em nunca confundir o papel do gateway (mediação) com o do backend (regra de negócio).

Perguntas frequentes

API Key ou OAuth: qual devo usar?

Use Verify API Key quando a identidade do app basta (APIs internas/parceiros) ou como identificador para Quota. Use OAuth quando precisa de credencial que expira, revogação sem trocar a chave em todos os consumidores, ou expõe a API fora do perímetro corporativo. A chave viaja em texto e não expira; o token, não.

Qual a diferença entre Spike Arrest e Quota?

Spike Arrest controla a taxa instantânea (picos por segundo/minuto) e suaviza rajadas; Quota controla o volume total numa janela (dia/mês) e impõe o limite contratual. Um espaça chamadas; o outro conta o acumulado. Use os dois juntos — são dimensões diferentes.

Onde as policies rodam — no gateway ou no backend?

Toda a lógica das policies roda na camada do API Management, não no backend. É justamente por isso que o gateway consegue rejeitar tráfego ruim, aplicar rate limit e transformar respostas sem tocar no código do S/4HANA.

Preciso mesmo definir o Identifier na Quota?

Sim. Sem Identifier (ex.: ref="client_id"), a quota vira global — um único consumidor pode consumir toda a cota e derrubar o limite dos demais. Com o Identifier, cada consumidor respeita o próprio teto contratual.

O gateway garante que meus dados não sejam corrompidos?

Ele cobre a forma: idempotência em retries, transporte de ETag/If-Match, validação de payload e contagem de $batch. A regra de negócio, o controle de lock e o commit ficam no backend/RAP. O gateway protege e mede; o backend decide e persiste.

Referências oficiais

• SAP Help — API Proxy;

• SAP Help — API Proxy Structure;

• SAP Help — Policies;

• SAP Help — Policy Types;

• SAP Help — VerifyAPIKey e OAuth;

• SAP Help — Designing Quota Policy;

• SAP Help — Lookup Cache;

• SAP Community — Policy Management;

• SAP Community — Steps to create API proxy;

• SAP Community — Building an API;

• SAP Community — Extracting Variables;

• SAP Community — JavaScript e serviceCallout;

• SAP Tutorials — Set Up API Management;

• SAP-samples — manage-apis-codejam;

• SAP — API Management (recursos 2026);

• SAP-PRESS — Complete Guide to SAP Integration Suite.