Troubleshooting APIs and API Manager

This guide covers common errors and issues encountered when configuring, publishing, and using APIs in Jitterbit API Manager. Start with the diagnostic steps below to gather information, then find your specific issue in the relevant section.

For a unified reference covering integration, automation, API management, EDI, and app development issues in one place, see the Harmony troubleshooting guide.

Diagnostic steps

These steps apply to most API Manager issues and are the recommended starting point.

Check the API logs

Review the API logs for request and response errors related to the affected API. By default, the logs show metadata such as status codes, error messages, and timestamps, which can help narrow down the cause.

To also capture the full request and response payloads, use debug mode, the best option for active troubleshooting: it captures request and response data along with detailed activity-level logging, and it turns off automatically on the date you set.

1. On the Settings tab of the API's configuration, turn on Enable debug mode until and set a date to keep it active. See the configuration reference for custom, OData, or proxy APIs.
2. Reproduce the request, then review the payloads in the API logs.

Check the Jitterbit system status

If an issue appears to affect all APIs or the API Manager interface itself rather than a single API, check the Jitterbit system status page and the known issues page before investigating further.

Authentication and security failures

Microsoft Entra ID OAuth: Security profile name cannot contain spaces

• Symptom: API calls using a Microsoft Entra ID (Azure AD) three-legged OAuth 2.0 security profile fail with an error from Microsoft indicating a reply URL mismatch:

  The reply URL specified in the request does not match the reply URLs configured for the application.
  

• Possible cause: The security profile name contains spaces. Spaces in the profile name cause the OAuth redirect URI to be constructed incorrectly, which does not match any of the reply URLs registered in the Azure app registration.

• Resolution:
  1. Open the security profile in API Manager and rename it to remove any spaces (for example, change My Profile to MyProfile or my-profile).
  2. In the Azure app registration, verify that the reply URLs registered there match the redirect URI that API Manager generates for the renamed profile.

Microsoft Entra ID 2-legged OAuth: OAUTH_INVALID_TOKEN_CODE error

• Symptom: API calls protected by a Microsoft Entra ID 2-legged OAuth 2.0 security profile fail with:

  Failed to validate authentication token - HttpErrorResponse: OAUTH_INVALID_TOKEN_CODE
  

• Possible cause: The aud claim in the JWT issued by Entra ID does not match the audience configured in the API Manager security profile. This usually indicates the Application ID URI in the Azure app registration is misconfigured, or the OAuth scope the client is requesting does not match the registered URI.

• Resolution:
  1. In the Azure portal, open the app registration assigned to this security profile and go to Expose an API.
  2. Confirm the Application ID URI is set to a valid URI in the format api://<Application (client) ID>.
  3. In the security profile, confirm the OAuth Scope is set to api://<Application (client) ID>/.default.
  4. Update the client application to request a token using this exact scope.
  5. If validation still fails after the audience and scope are correct, open the app registration's manifest and confirm requestedAccessTokenVersion is set to 2. A missing or different value can also cause token validation to fail.

Azure AD Graph API has been retired

• Symptom: API calls that previously worked with a Microsoft Entra ID (Azure AD) security profile fail with authentication errors.
• Possible cause: The security profile's app registration is still configured to use the Azure AD Graph API, which Microsoft retired on June 30, 2025. App registrations that were not migrated to Microsoft Graph fail when making requests.
• Resolution:
  1. In the Azure portal, migrate the app registration to Microsoft Graph.
  2. After migrating, update the app manifest by following the API permissions steps in the Microsoft Entra ID 2-legged OAuth security profile configuration.

Google or Salesforce identity provider: 2-legged OAuth is not supported

• Symptom: An API security profile configured with Google or Salesforce as the OAuth 2.0 identity provider fails when configured for 2-legged OAuth.
• Possible cause: Google and Salesforce OAuth 2.0 API security profiles do not support 2-legged OAuth.
• Resolution: Use a 3-legged OAuth 2.0 security profile for APIs that authenticate with Google or Salesforce as the identity provider.

Microsoft Copilot Studio: Basic authentication not supported

• Symptom: Connecting a Jitterbit custom API to Microsoft Copilot Studio (as a REST API tool) fails when the API's security profile uses basic authentication.
• Possible cause: Microsoft Copilot Studio does not support basic authentication. A Jitterbit custom API whose security profile uses basic authentication cannot be called from Copilot Studio.
• Resolution:
  1. In API Manager, open the security profile assigned to the API.
  2. Change the authentication type to API Key or OAuth 2.0, or remove the security profile from the API if the endpoint does not require authentication.
  3. Republish the API, then reconnect it in Microsoft Copilot Studio. See Connect a Jitterbit AI agent to Microsoft Copilot Studio.

"New API" button not visible despite correct organization role

• Symptom: The New API button does not appear in API Manager for a user who has an organization-level role but is not an organization administrator. Granting the user the Admin permission at the organization level makes the button appear, but also exposes all environments to the user.
• Possible cause: An organization-level role alone is not sufficient to create APIs. The role must also have Write access granted at the environment level for the specific environment where they need to create APIs.
• Resolution:
  1. In the Management Console, go to Environments and open the environment where the user needs to create APIs.
  2. For the user's role in that environment, confirm that Write access is enabled. If not, enable it and save.
  3. The New API button should now be visible for that environment.

Basic auth: Unexpected usernames appear in API logs when multiple security profiles are assigned

• Symptom: An API with two or more Basic auth security profiles assigned shows unexpected usernames in the API logs, including usernames that do not belong to either profile. Some requests fail with a 401 Unauthorized error.
• Possible cause: The browser or API client (such as Postman) has cached basic auth credentials from a previous session as a cookie. When the API is called again, the client sends the cached cookie first. If the cached credentials do not match either of the configured security profiles, the request is rejected and the unexpected username appears in the logs before authentication succeeds with the correct credentials.

• Resolution:

  1. Clear the browser's cookies and cache, or switch to an incognito or private browsing window, before retesting the API.
  2. Confirm the behavior is not present when a fresh request is made with no prior session cookies. If the error disappears, the issue is client-side credential caching and not a configuration problem.

  Note that any HTTP client that stores cookies (including browser-based tools and API testing utilities) can exhibit the same behavior.

401 Unauthorized with a valid IP allowlist (stale cache)

• Symptom: API calls return 401 Unauthorized even though the client IP is correctly listed in the security profile's trusted IP groups.
• Possible cause: A stale cache of legacy IP range entries on the security profile is overriding the active trusted IP groups.
• Resolution: Migrate the security profile from legacy IP ranges to the Trusted IP Groups model, the current allowlist mechanism: define the IPs as a trusted IP group and assign it to the profile. Disabling the Trust requests only from the following IP ranges setting on a profile that still uses legacy IP ranges permanently removes those ranges (a confirmation prompt warns of this), so migrate the IPs to a trusted IP group rather than toggling the setting off to clear the cache.

API publishing and deployment

Cannot publish an API: Subscription API limit reached

• Symptom: Creating or publishing an API fails with an error such as:

  You have reached Maximum no of API Service configured for your Jitterbit organization
  

• Cause: The organization has reached the maximum number of published API URLs allowed by its subscription. Each published custom API, OData API, or proxy API (and each of their published clones) uses one API URL; draft APIs do not count.

• Resolution: On the API Manager APIs page, check the Custom API URLs used and Proxy API URLs used counts, shown at the top of the page, against the totals allowed by your subscription. Unpublish or delete APIs that are no longer needed to free API URLs (draft APIs do not count against the limit). To raise the limit, contact your Customer Success Manager.

Published API returns 404 Not Found

• Symptom: Calling a published API returns a 404 error.
• Possible causes:
  • The Hits per minute limit in the assigned security profile is set to zero, blocking all requests. A change to the organization's subscription level can reset this limit, so an API that previously worked can start returning 404s.
  • The API's configuration, base URL, or visibility settings are incorrect.
  • A private API gateway is not recognizing the API after deployment.
  • The API has not been fully published or its metadata is incomplete.
• Resolution:
  • Open the security profile assigned to the API and confirm the Hits per minute value is set to a non-zero number. If the limit was recently reset (for example, after a subscription change), restore it to the intended value.
  • On the APIs page, verify the API has been successfully published and that its URL and visibility settings are correct.
  • If the API is served through a private API gateway, check the gateway installation and connectivity for any errors or misconfigurations.

Service URL exceeds maximum length (HTTP 414)

• Symptom: The API gateway returns:

  414 URI Too Large
  

• Possible cause: The constructed service URL (including base URL, service path, and any path or query parameters) exceeds 8,000 characters.

• Resolution:
  • Reduce the length of the service URL by shortening the service path or breaking the API into multiple endpoints.
  • For proxy APIs, confirm that the combination of the base URL and all defined service paths stays within the 8,000-character limit.

Proxy API: Service path parameters require an OpenAPI document

• Symptom: Configuring a proxy API service path with path parameters (for example, /resource/{id}) fails when entered manually, because the field does not accept curly bracket characters.
• Possible cause: Manually defined service paths in proxy APIs do not support the { and } characters used to define path parameters.
• Resolution: To use path parameters in a proxy API service path, provide an OpenAPI document that defines the paths and their parameters. API Manager auto-discovers the paths and their parameters from the OpenAPI specification rather than requiring them to be entered manually.

Cannot delete an API in API Manager

• Symptom: Deleting an API in API Manager fails: the interface shows a generic error and the API is not removed. The failure occurs in the browser before any delete request reaches the server, and appears as a JavaScript TypeError in the browser developer console.
• Possible cause: The user's role does not have the Admin permission. Deleting an API first checks which API Groups the API is associated with, and viewing the API Groups page requires the Admin permission: a role with only Write environment access can open the page but cannot read its contents. When the role cannot read the API groups, that check receives a value the interface cannot process, and the deletion does not complete.
• Resolution: Have a user whose role has the Admin role permission perform the deletion. Granting the affected role the Admin permission also works, but that is a broad organization-level elevation, so prefer having an existing administrator delete the API.

API environment cannot be changed after creation

• Symptom: An API was created in the wrong environment and needs to be moved, but the environment field is not editable.
• Possible cause: The environment is set at API creation time and cannot be changed afterward.
• Resolution:
  • To move a custom or proxy API to a different environment, clone the API from the APIs page and select the correct environment during cloning.
  • Alternatively, export the API from its current environment and import it into the target environment.

CORS enabled: OPTIONS requests run without authentication

• Symptom: After enabling CORS on a custom or proxy API, the OPTIONS HTTP method processes requests without authentication.
• Possible cause: Enabling CORS causes operations using the OPTIONS method to run without authentication. This is required to support browser preflight requests, but it means any OPTIONS request reaches the operation without passing through the security profile.
• Resolution:
  • If the API does not use OPTIONS for sensitive operations, no action is required. This is expected behavior when CORS is enabled.
  • If authenticated handling of OPTIONS is required, disable CORS on the API or restructure the operation to detect and handle unauthenticated preflight requests explicitly.

Cloud proxy API: Target API must be publicly accessible

• Symptom: A proxy API using the Jitterbit-hosted cloud API gateway returns errors or cannot reach the target API.
• Possible cause: When using the cloud API gateway, the API being proxied must be accessible from the public internet. APIs behind a firewall or on a private network cannot be reached by the cloud gateway.
• Resolution:
  • Confirm the target API is reachable from the public internet, even if it is secured.
  • If the target API must remain behind a firewall, deploy a private API gateway on the same private network instead of using the cloud API gateway.
  • To allowlist the cloud gateway IP addresses so the gateway can access the proxied API, see Allowlist information.

Show Request & Response Payloads setting has no effect for proxy APIs

• Symptom: The Show Request & Response Payloads in Logs toggle appears in a proxy API's settings but enabling it has no effect on log output.
• Possible cause: Request and response payload logging is not supported for proxy APIs. The toggle is visible in the configuration interface but does not function for this API type.
• Resolution: To capture request and response payloads, use a custom API that calls the same endpoint, where the Show Request & Response Payloads in Logs setting is supported.

Performance and timeouts

HTTP 504 Gateway Timeout

• Symptom: API calls return:

  504 Gateway Timeout
  

  This typically occurs after the gateway's timeout window (30 to 180 seconds, depending on the API's Timeout setting).

• Possible causes:

  • The API URL is malformed, or path parameters are not being handled correctly, causing the gateway to fail when routing the request.
  • The backend operation or external service is too slow to respond within the gateway's timeout window, for example because of large payloads or complex transformation logic.
  • The request cannot be assigned to an available agent, for example because the agent group is at full concurrency or under heavy load, so it times out at the gateway before the operation runs. A sign of this case is that the failed request has no corresponding entry in the operation logs.

• Resolution:

  • Verify the API URL is correctly formed. If the API uses path parameters, consider adding a script to the operation that explicitly parses the URL and captures the parameter values.
  • If the timeout is caused by a slow backend, review the operation and its transformation logic for performance bottlenecks, particularly large data payloads or slow external calls, and reduce the slow step.
  • If the operation genuinely requires more time than the current setting allows, increase the timeout on the API settings tab. The API timeout (default 30 seconds, maximum 180 seconds) is independent of the Studio operation timeout; the operation timeout is used only on private agents when the EnableAPITimeout setting is enabled in the agent configuration.
  • If the operation cannot complete within the maximum timeout, or a real-time response is not required, redesign the API's operation to start the long-running work asynchronously (for example, by calling it with RunOperation in asynchronous mode) so the API can return a response without waiting for it to finish. See Manage asynchronous operations.
  • For intermittent timeouts, add retries so a transient failure is re-attempted: use the HTTP v2 connection's built-in retry settings for outbound calls, or a scripted RunOperation retry loop with a delay between attempts.
  • If timeouts correlate with agent load, review agent capacity: run API-serving operations on agents separate from heavy ETL workloads, and add agents to the group if it is saturated. See Optimize and improve the performance of Jitterbit private agents.

Private gateway returns a 400 "verify Jitterbit Services" page with no API log entry

• Symptom: Requests through a private API gateway intermittently fail with an HTTP 400 response. Instead of a normal API response, the caller receives an HTML error page similar to:

  Error connecting to Jitterbit Services. Please verify that all Jitterbit Services are running on your Jitterbit Agent machine - including the Apache server and Process Engine.
  

  No entry appears in the API logs for the failed request, because the request never reached an operation.

• Possible cause: The private agent group is overloaded and has no available Apache worker threads to accept jobs from the private API gateway. When no worker thread is free, the gateway-to-agent handoff fails with a connection reset before the request can be logged or executed.

• Resolution:
  1. Add more agents to the agent group to distribute load, and confirm the agent hosts have sufficient CPU and memory.
  2. Monitor the agents' Apache worker thread usage. If native observability is enabled, review the Apache Thread Capability, Apache idle workers, and Apache busy workers charts (see Dashboards) to confirm whether threads are being exhausted during the failures.
  3. If the agents consistently run out of Apache worker threads even after scaling, contact Jitterbit support to review the agents' Apache worker thread capacity (the MaxRequestWorkers setting). Do not change the Jitterbit Apache configuration files unless directed by Jitterbit support. See Apache configuration files.

Display and synchronization

API Portal not reflecting project changes

• Symptom: The API Portal shows outdated project names or attributes after a project is renamed or updated.
• Possible cause: The API Portal did not automatically synchronize after the project was changed.
• Resolution:
  1. To refresh all custom and proxy APIs in the environment, open the Portal Manager and click Regenerate Docs. To update a single API, open its Documentation tab on the APIs page and click Save & Publish.
  2. Verify the updated information is correctly reflected on the API Portal.

Security profile changes take several minutes to take effect

• Symptom: An API continues behaving as if an old security profile configuration is active even after the profile has been updated and saved.
• Possible cause: Security profiles are cached on the API gateway. Changes to an active security profile do not take effect immediately.
• Resolution:
  1. Wait several minutes after saving a security profile change before testing the affected API.
  2. If the issue persists after 10 minutes, confirm the change was saved correctly by reopening the security profile.

Deleting an API does not update the API Portal documentation

• Symptom: After deleting an API, its OpenAPI documentation remains visible on the API Portal.
• Possible cause: The API Portal documentation is not automatically updated when an API is deleted from API Manager.
• Resolution:
  • After deleting an API, open the Portal Manager and manually remove or update the API's documentation entry there.
  • Alternatively, use the Documentation tab for the API before deleting it to remove the Portal entry first.

Security profile cannot be deleted while still assigned to a published API

• Symptom: Attempting to delete a security profile fails or the delete option is unavailable, even after unassigning the profile from an API.
• Possible cause: After removing a security profile from an API's configuration, the API must be saved and republished before the profile is considered fully unassigned. Until the API is republished, API Manager still treats the profile as in use.
• Resolution:
  1. After unassigning the security profile from the API, click Save and then Publish the API.
  2. Once the API has been republished with the updated configuration, the security profile will no longer show as in use and can be deleted.

Private gateway issues

2-legged OAuth falls back to 3-legged on private gateway versions before 10.48

• Symptom: A security profile configured for 2-legged OAuth uses 3-legged OAuth instead when served through a private API gateway.
• Possible cause: Private API gateways earlier than version 10.48 do not support 2-legged OAuth. If the gateway version is below 10.48, the security profile falls back to 3-legged OAuth even when 2-legged OAuth is configured.
• Resolution:
  1. Check the version of the private API gateway serving the API.
  2. Upgrade the gateway to version 10.48 or later to enable 2-legged OAuth support.

Multi-gateway ALB: All containers must be on the same host

• Symptom: In a containerized multi-gateway environment behind an application load balancer (ALB), API calls intermittently fail or payloads cannot be retrieved even though individual gateways appear healthy.
• Possible cause: When using a containerized private API gateway with an ALB, all gateway containers must run on the same host machine. Containers deployed across different hosts cannot coordinate payload retrieval, causing intermittent failures.
• Resolution:
  1. Confirm all private API gateway containers in the group are running on the same physical or virtual host.
  2. If containers are spread across multiple hosts, consolidate them onto a single host.
  3. For multi-host deployments, review the ALB configuration in the gateway installation guide for additional configuration requirements.

Private gateway: Custom SSL configuration is overwritten by upgrades

• Symptom: After upgrading a private API gateway, custom SSL protocol or cipher settings are no longer applied and the gateway reverts to default TLS behavior.
• Possible cause: The private API gateway upgrade process overwrites the on-premise configuration file (/usr/local/openresty/nginx/conf/onpremise.conf). Any manual changes to this file, including custom SSL protocol restrictions or cipher lists, are lost during the upgrade.
• Resolution:
  1. Before upgrading the private API gateway, back up the on-premise configuration file.
  2. After the upgrade completes, reapply your custom SSL settings to the new configuration file.

Private gateway returns HTTP 507 or "No such file or directory"

• Symptom: Private API gateway endpoints return 507 Insufficient Storage. Gateway logs show:

  could not open payload file: No such file or directory
  

  even when there is ample disk space on the gateway hosts.

• Possible cause: Here, 507 means the gateway could not open the hosted payload or response file for the request; it does not necessarily mean the host is out of storage. In a multi-node private API gateway behind a load balancer, this can happen when the node serving a request cannot access a hosted file that another node created, because those files are local to each node.

• Resolution:

  1. Confirm the gateway hosts are not genuinely out of storage by checking disk and inode usage (df -h and df -i). Free space and retest only if they are actually full.
  2. If the gateway runs as multiple nodes behind a load balancer, confirm the load balancer routes each request and its response consistently to the same node, because hosted payload and response files are local to the node that created them. For containerized gateways, see Multi-gateway ALB: All containers must be on the same host.
  3. If the error persists, enable trace logging on the gateway (set traceLogsEnabled to true in the gateway configuration) and contact Jitterbit support with the resulting trace logs, the gateway logs (/opt/jitterbit/var/log/api-gateway), the NGINX or OpenResty logs, and ls -lR output for the hosted-files directories on each node. Support can check server-side conditions that are not customer-configurable, such as the host-to-environment mapping, stale private-domain entries, and file permissions.

Private gateway install or upgrade fails with missing dependencies

• Symptom: Running yum install to install or upgrade a Linux (RPM) private API gateway to version 10.62 or later fails with missing-dependency errors:

  Nothing provides geoip-devel needed by jitterbit-api-gateway-11.x.x-x.x86_64
  Nothing provides libGeoIP.so.1()(64bit) needed by jitterbit-api-gateway-11.x.x-x.x86_64
  

• Possible cause: Private API gateway version 10.62 and later require the geoip-devel and libGeoIP packages, which are provided by the EPEL repository. The documented install enables EPEL before installing the gateway. The error occurs when that step is skipped, or when the gateway host has no internet access and cannot reach EPEL to download the packages.

• Resolution:

  • On a gateway host with internet access, enable the EPEL repository before installing the gateway, as described in Install a private API gateway: run yum install https://dl.fedoraproject.org/pub/epel/epel-release-latest-8.noarch.rpm, then re-run the gateway install.
  • On an air-gapped host with no internet access, installing the epel-release package alone only adds the repository definition; it does not download the geoip-devel and libGeoIP packages. On a machine with internet access, download those packages and their transitive dependencies, transfer them to the gateway host, and install them in dependency order with yum install <package.rpm> before re-running the gateway install.

Private gateway self-test returns "Failure, test call to API failed"

• Symptom: The private API gateway command-line self-test utility returns:

  Failure, test call to API failed
  

• Possible cause: On private API gateway versions 11.30 and earlier, the self-test utility creates a test API that is missing required fields (Service Name and Path), causing the test call to fail.

• Resolution:
  • Upgrade the private API gateway to version 11.31 or later, which resolves this automatically.
  • If upgrading immediately is not possible: open the API configuration for the API named ApiGatewayTest, populate the Service Name field with any value (for example, service), set Path to /, save and publish, then re-run the self-test utility.

Analytics and API behavior

OData $count or $inlinecount returns an error when no records match

• Symptom: An OData API query using the $count or $inlinecount system query options returns an error rather than 0 when no records match the filter.
• Possible cause: By default, an OData API returns an error rather than 0 when a $count or $inlinecount query matches no records.
• Resolution: On private agents running version 11.32 or later, set the $noErrorOnZeroCount OData parameter to true in the OData API configuration. This causes $count queries to return 0 instead of an error when no records match.

Proxy API: Request header hyphens replaced with underscores

• Symptom: A proxy API operation receives request headers with hyphens replaced by underscores (for example, X-Custom-Header arrives as X_Custom_Header), causing header lookups to fail.
• Possible cause: Proxy APIs have a disable-hyphen-replacement setting that controls whether hyphens in request header names are replaced with underscores. For new proxy APIs, this setting defaults to true (replacement disabled). Older proxy APIs may have it set to false, causing the replacement.
• Resolution:
  • In the proxy API configuration, verify the disable-hyphen-replacement header setting. To preserve hyphens in header names, ensure the setting is true.
  • If the proxy API was created before this default was introduced and replacement is occurring unexpectedly, update the setting to true and republish the API.

Operation logs are not visible for API-triggered operations when debug mode is off

• Symptom: After calling an API, the API log shows the call ran successfully, but no operation log appears in the Runtime page for the operation the API triggered. Calls to WriteToOperationLog from within the operation also produce no visible log entries.
• Possible cause: When an operation is triggered through a published API, successful runs do not appear in the operation logs by default. Unsuccessful operations are always logged; only successful operation logs, and any WriteToOperationLog output from successful runs, are hidden. Successful runs appear only when Enable debug mode until (an API Manager setting) or Operation debug logging (an agent setting) is active.
• Resolution:
  1. To see successful operation logs and WriteToOperationLog output, turn on Enable debug mode until for the API on the API settings tab, or enable Operation debug logging on the agent.
  2. To also capture the raw request and response data and payloads, either turn on Enable debug mode until (as in step 1), or combine Operation debug logging with both Show Request & Response Payloads in Logs and Verbose logging. Which data each setting captures depends on the combination enabled; for the full breakdown, see API request and response data.
  3. Disable debug mode after collecting the logs you need, since leaving it on increases log volume.

API payload available on agent for 2 days

• Symptom: A workflow that retrieves an API request payload from the agent more than 2 days after the API was called cannot find the payload.
• Possible cause: API request payloads for custom APIs and OData APIs are stored on the agent for a maximum of 2 days. After that period, the payload is available only if the operation already wrote it to a persistent storage connector (such as Temporary Storage, File Share, or a database).
• Resolution:
  • Design operations that consume API request payloads to process the data immediately when the API is called rather than deferring payload retrieval.
  • If the payload must be retained for longer processing, write it to a persistent storage location in the initial API-triggered operation.

API Logs page retains previous filter selections

• Symptom: The API Logs page is not showing expected log entries even though the API is running successfully.
• Possible cause: The API Logs page remembers filter selections from the previous session. A previously applied filter may be hiding expected results.
• Resolution: On the API Logs page, review all active filters and clear any that may be excluding the expected entries.

Unpublished APIs do not appear in the Analytics APIs dropdown

• Symptom: An API does not appear in the APIs dropdown on the Analytics page, so analytics data for that API cannot be filtered.
• Possible cause: Only currently published APIs appear in the APIs dropdown. APIs that have been unpublished are excluded from the dropdown even if API logs for those APIs exist.
• Resolution:
  • Confirm the API has been published. To view analytics data, the API must be in a published state.
  • To view log entries for an unpublished API, use the API Logs page instead. Log data remains available there but cannot be filtered by API name.

Rate limiting

Error 429: Monthly API hit allowance exceeded

• Symptom: All APIs in the organization suddenly return HTTP 429 errors.
• Possible cause: The organization has exhausted its monthly API hit allowance as defined by its license. When the allowance is exceeded, all API calls are rejected with a 429 response for the remainder of the month.
• Resolution:
  • Check the current hit count against your monthly allowance on the APIs page. The allowance resets on the first day of the following month.
  • To avoid reaching the limit, configure rate limits at the environment or security profile level using the Hits per minute setting to spread load and enforce consumption limits per consumer.
  • To increase your organization's monthly allowance, contact your Customer Success Manager.

Error 429: Consumer IP not in trusted IP range

• Symptom: A specific consumer or application receives HTTP 429 errors when calling an API, while other consumers can call the same API successfully.
• Possible cause: The security profile assigned to the API has trusted IP groups configured. Requests from IP addresses outside the allowed ranges are rejected with a 429 response.
• Resolution:
  1. Open the security profile assigned to the API and review its trusted IP group configuration.
  2. Add the consumer's IP address or address range to an existing trusted IP group, or create a new trusted IP group that includes the required addresses.

Platform-level rate limit: 200 requests per minute

• Symptom: APIs hosted on the Jitterbit-managed cloud API gateway are throttled or rejected with a 429 Too Many Requests response under high traffic, even when security profile rate limits have not been reached.
• Possible cause: The Jitterbit-managed cloud API gateway enforces a platform-level limit of 200 API requests per minute per organization, shared across all API types (custom, proxy, and OData). This limit does not apply to private API gateways.
• Resolution:
  • Review your API traffic patterns and distribute calls over time if possible to stay within the 200 requests per minute limit.
  • If your use case requires sustained throughput above this limit, deploy a private API gateway where throughput is determined by the capacity of the host server rather than a platform-level cap.

Network and connectivity

Zscaler or SSL-intercepting firewall blocks API access

• Symptom: API calls fail with certificate errors, or backend endpoints cannot reach APIs secured with TLS when routed through a Zscaler-managed or similar SSL-inspecting network.
• Possible causes:
  • Zscaler and similar security proxies perform SSL/TLS inspection by intercepting HTTPS traffic and re-signing it with their own CA certificate. Client systems that do not trust the Zscaler root CA reject the connection.
  • Manually importing the Jitterbit certificate into the trust store is not a reliable workaround: when Jitterbit renews its certificate, the manually imported copy becomes stale and breaks the connection again.
• Resolution:
  • Install the Zscaler root CA certificate in the OS or browser trust store on the systems making the API calls, so that Zscaler-re-signed certificates are trusted.
  • For tools such as curl, wget, or openssl, configure them to use the HTTP proxy defined in the Zscaler environment.
  • Request a Zscaler policy exception for the Jitterbit API gateway hostnames to bypass SSL inspection for those specific destinations.
  • Review the organization's PAC (proxy auto-configuration) file rules to confirm Jitterbit endpoints are handled correctly.
  • Do not manually import the Jitterbit leaf certificate into a trust store as a workaround: use the Zscaler root CA instead to avoid breakage when Jitterbit renews its certificate.