Skip to main content
Solved

Print Manager Error: API key is invalid

  • September 9, 2026
  • 1 reply
  • 21 views
ROVECH
Hero (Partner)
Forum|alt.badge.img+7

26R1. Using External Reports Gateway. When testing via External Reports Gateway Settings: Test Connection, an Application Message is created and a REST message is sent to the external service.

However when printing this error message comes up in the Print Manager

I added an additional header in the Routing Address since my external service is only accepting x-api-key<key>, an IFS only sends Authorization: Bearer <key>.

Adding x-api-key=<key> in the additional header section works when testing. Since no application message is created when printing I am unsure this is an issue when printing.

 

Any ideas?

Best answer by Jane Perry

Hi.  I found the followig information -

 

The behavior you are experiencing is due to a fundamental difference in how Test Connection vs. Actual Printing works in IFS Cloud.

Why "Test Connection" Works vs. Why "Printing" Fails

  1. Test Connection (Uses IFS Connect Routing Address):

    • When you perform Test Connection, IFS executes the test through the IFS Connect framework.

    • This generates an Application Message and uses the Routing Address, where your custom x-api-key header is attached and sent to the endpoint.

  2. Actual Printing (Bypasses IFS Connect):

    • During actual printing, the Print Manager / External Reports Gateway rendering engine makes a direct, synchronous HTTP/REST call from the print service/microservice to the external service URL.

    • Actual print rendering does NOT go through IFS Connect Application Messages or Routing Rules.

    • Because it bypasses IFS Connect, any Additional Headers defined on the Connect Routing Address are ignored.

    • Instead, the print engine sends the API Key configured in the External Reports Gateway settings using the hardcoded default header format:
      Authorization: Bearer <key>

    • Since your external service expects x-api-key: <key> and rejects Authorization: Bearer <key>, the external service returns an HTTP 401/403 unauthorized response, which Print Manager logs as API key is invalid.

To resolve this issue, you can use one of the following approaches:

Option 1: Configure an API Gateway / Reverse Proxy (Recommended)

Place an API Gateway or Reverse Proxy (such as Azure API Management, APISIX, or NGINX) between IFS Cloud and your external reporting service:

  • IFS Print Manager sends requests to the API Gateway with Authorization: Bearer <key>.

  • The API Gateway strips Authorization: Bearer and rewrites it to x-api-key: <key> before forwarding the request to your external service.

Option 2: Update the External Service to Accept Authorization: Bearer

Modify your external reporting service endpoint authentication logic to accept Authorization: Bearer <key> in addition to (or instead of) x-api-key.

Option 3: Route Printing via Report Rules & IFS Connect (If Applicable)

If your printing flow allows processing via IFS Connect (e.g., generating PDF output to an outbound channel rather than using direct synchronous rendering):

  • Configure a Report Rule to route the report output through an IFS Connect Outbound Routing Rule linked to your Routing Address.

  • This forces the print output through IFS Connect, ensuring the x-api-key additional header is included.

 

I hope this information helps.  Thanks!  Jane

1 reply

Hero (Employee)
Forum|alt.badge.img+9
  • Jane Perry
  • Hero (Employee)
  • Answer
  • September 9, 2026

Hi.  I found the followig information -

 

The behavior you are experiencing is due to a fundamental difference in how Test Connection vs. Actual Printing works in IFS Cloud.

Why "Test Connection" Works vs. Why "Printing" Fails

  1. Test Connection (Uses IFS Connect Routing Address):

    • When you perform Test Connection, IFS executes the test through the IFS Connect framework.

    • This generates an Application Message and uses the Routing Address, where your custom x-api-key header is attached and sent to the endpoint.

  2. Actual Printing (Bypasses IFS Connect):

    • During actual printing, the Print Manager / External Reports Gateway rendering engine makes a direct, synchronous HTTP/REST call from the print service/microservice to the external service URL.

    • Actual print rendering does NOT go through IFS Connect Application Messages or Routing Rules.

    • Because it bypasses IFS Connect, any Additional Headers defined on the Connect Routing Address are ignored.

    • Instead, the print engine sends the API Key configured in the External Reports Gateway settings using the hardcoded default header format:
      Authorization: Bearer <key>

    • Since your external service expects x-api-key: <key> and rejects Authorization: Bearer <key>, the external service returns an HTTP 401/403 unauthorized response, which Print Manager logs as API key is invalid.

To resolve this issue, you can use one of the following approaches:

Option 1: Configure an API Gateway / Reverse Proxy (Recommended)

Place an API Gateway or Reverse Proxy (such as Azure API Management, APISIX, or NGINX) between IFS Cloud and your external reporting service:

  • IFS Print Manager sends requests to the API Gateway with Authorization: Bearer <key>.

  • The API Gateway strips Authorization: Bearer and rewrites it to x-api-key: <key> before forwarding the request to your external service.

Option 2: Update the External Service to Accept Authorization: Bearer

Modify your external reporting service endpoint authentication logic to accept Authorization: Bearer <key> in addition to (or instead of) x-api-key.

Option 3: Route Printing via Report Rules & IFS Connect (If Applicable)

If your printing flow allows processing via IFS Connect (e.g., generating PDF output to an outbound channel rather than using direct synchronous rendering):

  • Configure a Report Rule to route the report output through an IFS Connect Outbound Routing Rule linked to your Routing Address.

  • This forces the print output through IFS Connect, ensuring the x-api-key additional header is included.

 

I hope this information helps.  Thanks!  Jane

Terms & ConditionsAccessibility statement