Skip to Content

Jitterbit private API gateway

Introduction

A private API gateway, hosted on a private network, handles these security features and tasks involved in accepting and processing API Manager API calls:

  • Traffic management.
  • Authorization and access control.
  • Rate limiting.
  • API payload processing.

You can install and run a private API gateway on Linux, or run one as a Linux-based Docker container.

A private API gateway is a local gateway for processing APIs directly from your own servers. API Manager security features are configured at the API level or security profile level and are cached in the private API gateway, which are then referenced during API runtime as described below.

Private API gateway system architecture

Using a private API gateway provides these additional advantages over the Cloud API gateway:

  • Internal Network: The private API gateway and its agents can be restricted solely to an internal network behind a firewall and not be accessible from the Internet.

    Note

    If your private API gateway installation is behind a firewall within your network, you must allowlist necessary Jitterbit services.

  • Payload Security: API response payloads never pass through Jitterbit's systems.

  • Control: You have control over the private API gateway's hardware and software environment, ensuring that it meets your company's standards.
  • Domain Name: The base API endpoint URL can be configured to be a subdomain of a domain name you control, rather than a subdomain of the Harmony region (jitterbit.cc, jitterbit.eu, or jitterbit.net). An alternative to using a private API gateway for controlling the domain name is to use a third-party tool such as Cloudflare or a DNS proxy to route a custom domain name to the base URL.

This diagram displays the system architecture of a custom API deployed on-premises with a private agent and a private API gateway:

attachment

  1. An API consumer makes a call to the API located at the private API gateway.

  2. The private API gateway references the cached security profiles (if applicable) and API metadata to perform authentication and access control tasks. If access to the API is denied, the private API gateway will return an appropriate HTTP response and status to the API consumer. If access to the API is granted, the API request is routed to the messaging service, which routes requests for agent groups.

  3. The private agent receives the request from the messaging service.

  4. The private agent references the API operation specified during the custom API configuration and triggers the deployed operation.

  5. The operation responds with an API payload consistent with the response type selected during the custom API configuration.

  6. The API response payload is routed from the private agent back to the private API gateway, which extracts the API payload and sets the final HTTP response and status. The HTTP response and status is sent to the API consumer.

    Note

    Unless the operation being triggered by the API call is using Temporary Storage, the API response payload will remain on the agent for a maximum of two days. The API response payload will remain on the private API gateway for no longer than the API gateway timeout of 15 seconds.

  7. Runtime status information and logs of running operations are sent to the transaction logs database.

    Note

    Consumer data is not stored in the transaction logs database unless debug mode is enabled during custom API configuration.