Skip to content

API Gateway Integration Guide

Purpose

This guide explains how to integrate APIgator into your API architecture from an implementation and design perspective. It is intended for solution and enterprise architects designing data protection controls within API-driven systems.

The goal is to introduce a consistent, policy-driven control point that protects sensitive data in motion and, where required, at ingress and egress.

Architectural Role

Within an API architecture, eXate acts as a stateless policy enforcement service that:

  • Accepts structured payloads and contextual metadata
  • Evaluates policies based on identity, attributes, and data classification
  • Returns a transformed payload (masked, encrypted, tokenised, or filtered)

It is typically inserted as a synchronous step in the request or response path.

Reference Flow

  1. Client invokes API
  2. Gateway or application calls backend service
  3. Payload is sent to eXate Protect, which applies policies using context (user, scopes, source, etc.)
  4. Transformed payload is returned and the response is forwarded to the client
flowchart LR
    classDef step fill:#eaf3fa,stroke:#01328e,stroke-width:2px,color:#01328e,font-weight:bold;
    classDef highlight fill:#add8e6,stroke:#01328e,stroke-width:2px,color:#01328e,font-weight:bold;

    A["Client"]:::step -->|"1. REST API call"| B["Gateway / Sidecar"]:::step
    B -->|"2"| C["Service / Container"]:::step
    B <-->|"3"| D["APIgator"]:::highlight
    D --> E["GatorAId"]:::step
    B -->|"4. Response"| A

This pattern keeps protection externalised from business logic while remaining inline with API execution.

Core Integration Pattern

The Protect service is a REST API secured by OAuth Bearer token.

Authentication

  • Obtain a token from the eXate auth endpoint
  • Cache the token (TTL ~10 minutes)
  • Reuse until expiry to minimise latency

Protect Request Construction

Include:

  • Payload (request or response)
  • Protection intent (implicit via policy)
  • Context: identity claims/scopes, API keys/client metadata, source system/route, IP or network attributes

Invocation

  • Call eXate Protect synchronously
  • Expect a transformed payload in response

Response Handling

  • Replace the original payload
  • Continue the API flow

Integration Options

1. API Gateway Integration

Apigee (X and Hybrid)

Implementation is policy-driven using shared flows and service callouts.

Design approach:

  • Encapsulate eXate logic in a reusable Shared Flow
  • Attach via FlowHooks for global enforcement, or per-proxy for selective rollout

Flow components:

  • Service callout for token generation and caching
  • Policy to construct the Protect request from flow variables
  • Service callout to the eXate endpoint
  • Response assignment to overwrite the payload

Apigee Hybrid specifics:

  • Execution occurs in the customer-managed runtime plane (Kubernetes)
  • eXate calls originate from this runtime
  • Data is processed within the same execution environment as API traffic

This model is suitable where runtime locality and network control are required.

Kong

Integration is achieved via routing and plugins.

Design approach:

  • Define routes requiring protection
  • Use Request Transformer to construct the Protect request
  • Forward to eXate as an upstream service
  • Use Response Transformer to return the processed payload

Optional: a custom plugin for tighter control and performance optimisation.

NGINX (Reverse Proxy / Lightweight Gateway)

Used where a full gateway is not present.

Design approach:

  • Intercept responses at the proxy layer
  • Invoke eXate using subrequests or Lua (OpenResty)
  • Replace the response body inline

Implementation options: Lua HTTP client for dynamic calls, or the subrequest pattern for simpler routing.

Considerations for design: enable response buffering, maintain connection reuse, handle payload size constraints.

2. Application-Level Integration

Used when no gateway exists, or when protection must be embedded within services.

Design approach:

  • Introduce a protection layer within service code or middleware
  • Centralise eXate invocation in shared libraries where possible

Patterns:

  • Response protection: after data retrieval, call eXate, return the protected payload
  • Ingress protection: before persistence, tokenise or encrypt sensitive fields
  • Reconstruction: on read operations, decrypt or detokenise based on user context

Recommended implementation: wrap eXate calls in a service or SDK layer, standardise request construction, and externalise configuration for policies and endpoints.

Supported environments: Java, Node.js, Python, .NET; microservices and serverless.

Data Protection Patterns

Inline Response Filtering: mask or remove fields dynamically, driven by user entitlements and policy.

Tokenisation at Ingress: replace sensitive values before storage, maintaining referential integrity via tokens.

Context-Aware Reconstruction: reveal or partially reveal data, controlled by identity and policy.

Performance and Design Considerations

  • Token caching is essential to reduce auth overhead
  • Keep Protect calls lightweight and synchronous
  • Use connection pooling to minimise latency
  • Consider payload size and serialization costs
  • Evaluate placement (gateway vs application) based on latency sensitivity and control requirements

Validation Approach

  • Validate payload transformations against policy expectations
  • Test with multiple identity contexts
  • Confirm no sensitive data leakage in logs or responses

Resources

Summary

eXate introduces a consistent, externalised control point for data protection within API architectures. It can be deployed at the gateway or application layer, enabling architects to enforce fine-grained data policies without coupling protection logic to backend systems.