Skip to Content

API types in Jitterbit API Manager

Overview

Within API Manager, you can create and publish three types of APIs:

Each type of API interacts with Harmony uniquely within the system architecture as described below.

For more information on Jitterbit security and system architecture, see Jitterbit security and architecture white paper.

Custom API

Custom APIs expose a Harmony operation for consumption. An operation must first be created and deployed to Harmony and can be any Integration Studio or Design Studio operation. The existing operation is then referenced during the configuration of the custom API and is called and consumed by an API consumer. Custom APIs are routed through Jitterbit agents (either cloud agent groups or private agents).

This diagram displays how a custom API behaves in the system architecture when deployed with a cloud agent and a cloud API gateway:

diagram cutsom API cloud deployment pp

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

  2. The custom API request is routed through the cloud API gateway to the messaging service, which routes requests for agent groups.

  3. A cloud agent receives the request from the messaging service.

  4. The cloud agent references the custom 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 payload is routed from the cloud agent back to the API consumer.

    Note

    Unless the operation being triggered by the API call is using Temporary Storage, the API payload will remain on the agent for only two days.

  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.

For information on configuring a custom API, see Custom API configuration.

OData service

OData services expose a Design Studio API entity operation for consumption. The API entity operation must first be created and deployed to Harmony. The existing API entity operation is then referenced during the configuration of the OData service and is called and consumed by an API consumer. OData services are routed through Jitterbit agents (either cloud agent groups or private agents).

This diagram displays how an OData service behaves in the system architecture when deployed on-premises with a private agent and a private API gateway:

diagram OData service on premises deployment pp

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

  2. The OData service request is routed through the private API gateway.

  3. The request is received by the messaging service, which routes requests for agent groups.

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

  5. The private agent references the OData service API entity operation in Harmony and triggers the deployed entity operation.

  6. The operation responds with an API payload that is routed from the private agent through the private API gateway back to the API consumer.

    Note

    Unless the operation being triggered by the API call is using Temporary Storage, the API payload will remain on the agent for only two days.

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

    Note

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

  8. Logs on the private agent can be optionally synced to the transaction logs database within the Harmony.

For information on configuring an OData service, see OData service configuration.

Proxy API

Unlike custom APIs or OData services, which expose a Harmony operation for consumption, proxy APIs are used with an existing third-party API and are not routed through Jitterbit agents. The API being proxied must be accessible to the gateway processing the API, either the cloud API gateway or a private API gateway:

  • Cloud API gateway: If using the API gateway that Jitterbit hosts on Harmony, the existing API must be accessible publicly, even if secured. That is, the API you are trying to proxy cannot be behind a firewall. To allowlist the cloud API gateway IP addresses to allow the gateway access to the API being proxied, see Allowlist information and navigate to https://services.jitterbit for your region.

  • Private API gateway: If using a private API gateway, the existing API must be accessible by the private API gateway.

This diagram displays how a proxy API behaves in the system architecture when processed by the cloud API gateway:

diagram proxy API cloud deployment pp

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

  2. The proxy API call is routed through the cloud API gateway and sent to the third-party API being proxied.

  3. The API payload is routed through the cloud API gateway back to the API consumer.

  4. The third-party API responds with an API payload that is routed to the cloud API gateway back to the API consumer.

  5. Runtime status information is sent to the transaction logs database.

    Note

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

For information on configuring a proxy API, see Proxy API configuration.