# Check Point Harmony Endpoint Integration Fails on Log Retrieval (404) Despite Successful Manual API Tests **URL:** \ **Category:** Beats\ **Tags:** fleet, filebeat\ **Created:** [July 9, 2025, 5:46pm UTC](https://discuss.elastic.co/t/check-point-harmony-endpoint-integration-fails-on-log-retrieval-404-despite-successful-manual-api-tests/379962 "2025-07-09T17:46:13Z")\ **Posts on this page:** 3\ **Page:** 1
**Author:** ![Gustavo\_Colla](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/gustavo_colla/32/140064_2.png) [@Gustavo\_Colla](https://discuss.elastic.co/u/Gustavo_Colla)\ **Post date:** [July 9, 2025, 5:46pm UTC](https://discuss.elastic.co/t/check-point-harmony-endpoint-integration-fails-on-log-retrieval-404-despite-successful-manual-api-tests/379962/1 "2025-07-09T17:46:13Z")
Hello everyone, I'm facing a persistent issue with the **Check Point Harmony Endpoint Anti-Malware** integration and would appreciate any insights the community might have. The integration consistently fails to retrieve logs, and the agent logs show a `404 Not Found` error during the log retrieval API call. The strange part is that I have manually replicated the entire API workflow using `curl` from the same server, and every step succeeds, including the final data retrieval. **Check Point Harmony Endpoint Integration Version: 1.0.0** **The Problem in Detail:** The `checkpoint_harmony_endpoint.antimalware` data stream fails to ingest data. The agent logs show the following error message, indicating a failure at the final `/retrieve` step: `POST https://cloudinfra-gw-us[.]portal[.]checkpoint[.]com/app/laas-logs-api/api/logs_query/retrieve: {\"success\":false,\"error\":{\"status\":404,\"name\":\"Not Found\",\"details\":[\"Requested resource could not be found or expired\"]}}` **Troubleshooting Steps Performed:** I have performed a full manual test of the Check Point API using `curl`, and every step was successful. This seems to rule out issues with credentials, permissions, network connectivity, firewalls, or proxies. Here is the successful workflow I replicated: **1. Authentication:** I successfully obtained a Bearer Token. `curl -X POST 'https://cloudinfra-gw-us[.]portal[.]checkpoint[.]com/auth/external' \ -H 'Content-Type: application/json' \ -d '{ "clientId": "xxxxx", "accessKey": "xxxxx" }'` **Result:** `{"success":true, "data":{"token":"xxxxxx", "expires":"..."}}` **2. Submit Log Query:** Using the token, I successfully submitted a query for Anti-Malware logs and received a `taskId`. `curl -X POST 'https://cloudinfra-gw-us[.]portal[.]checkpoint[.]com/app/laas-logs-api/api/logs_query' \ -H 'Content-Type: application/json' \ -H 'Authorization: Bearer ' \ -d '{"filter": "product:\"Anti-Malware\"", "timeframe": {"startTime": "...", "endTime": "..."}}'` **Result:** `{"success":true, "data":{"taskId":"xxxxxxxxxxxxx"}}` **3. Check Query Status:** I polled the task status using the `taskId` and received a "Ready" state with a `pageToken`. `curl -X GET 'https://cloudinfra-gw-us[.]portal[.]checkpoint[.]com/app/laas-logs-api/api/logs_query/' \ -H 'Authorization: Bearer '` **Result:** `{"success":true, "data":{"state":"Ready", "pageTokens":["xxxxxxx"]}}` **4. Retrieve Log Data:** Finally, I used the `taskId` and `pageToken` to retrieve the data, and I successfully received a JSON object containing the log records. `curl -X POST 'https://cloudinfra-gw-us[.]portal[.]checkpoint[.]com/app/laas-logs-api/api/logs_query/retrieve' \ -H 'Content-Type: application/json' \ -H 'Authorization: Bearer ' \ -d '{"taskId": "", "pageToken": ""}'` **Result:** `{"success":true,"data":{"records":[...]}}` **Additional Steps Taken:** - I have tried completely removing and re-adding the integration in the agent policy. - I have confirmed the correct Data Center URL is being used. **My Question:** Given that all manual API calls work perfectly, why would the Elastic Agent integration fail at the final log retrieval step with a `404 Not Found`? Is this a known bug with this integration version, or are there any other internal configuration parameters (e.g., in the advanced YAML settings) that could be causing this discrepancy between the manual tests and the agent's execution? Thank you in advance for any help or suggestions. ---
**Author:** ![strawgate](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/strawgate/32/131008_2.png) [@strawgate](https://discuss.elastic.co/u/strawgate)\ **Post date:** [July 19, 2025, 1:59pm UTC](https://discuss.elastic.co/t/check-point-harmony-endpoint-integration-fails-on-log-retrieval-404-despite-successful-manual-api-tests/379962/2 "2025-07-19T13:59:12Z")
can you share the full configuration you've provided for the integration as well as a short snippet of the full log lines surrounding the error and including the error? Are you using the exact same access\_key and client\_id across your manual test and the integration test? you should also enable request tracing in the integration which will product an ndjson file on the endpoint with each request in it, it will almost certainly contain secrets but might reveal the difference between the request you're making and the request agent is making it's not fun to look at but if you look at the CEL for the integration [integrations/packages/checkpoint\_harmony\_endpoint/data\_stream/antimalware/agent/stream/cel.yml.hbs at main · elastic/integrations · GitHub](https://github.com/elastic/integrations/blob/main/packages/checkpoint_harmony_endpoint/data_stream/antimalware/agent/stream/cel.yml.hbs) you can get an idea of what fields are packed into each request ---
**Author:** ![Gustavo\_Colla](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/gustavo_colla/32/140064_2.png) [@Gustavo\_Colla](https://discuss.elastic.co/u/Gustavo_Colla)\ **Post date:** [August 4, 2025, 7:06pm UTC](https://discuss.elastic.co/t/check-point-harmony-endpoint-integration-fails-on-log-retrieval-404-despite-successful-manual-api-tests/379962/3 "2025-08-04T19:06:41Z")
Hello William, Thank you for your prompt response and your helpful suggestions. Answering your questions: I can confirm that the **exact same `clientId` and `accessKey`** are being used in both my manual `curl` tests and in the Fleet integration policy. Regarding the configuration and logs, your suggestion to enable **request tracing** was the key. The trace logs provided such a clear picture of the issue—a logic flaw rather than a simple configuration error—that I believe they contain all the necessary information. The logs revealed a significant difference in behavior between the different data streams within the same integration. Here is a side-by-side comparison of the trace logs from a failing stream (`antimalware`) and a working stream (`Anti-Bot`). ### 1. Failing Workflow: `antimalware` Data Stream This log shows the agent authenticating successfully but then immediately skipping to the final `/retrieve` step with a stale `taskId`, which results in the 404 error. **Step 1: Authentication request.** `{"log.level":"debug","@timestamp":"2025-08-04T15:03:03.862-0300","message":"HTTP request","url.original":"https://cloudinfra-gw-us.portal.checkpoint.com/auth/external","http.request.method":"POST","http.request.body.content":"{\"accessKey\":\"[REDACTED_ACCESS_KEY]\",\"clientId\":\"[REDACTED_CLIENT_ID]\"}"}` **Step 1: Authentication response - SUCCESS (200 OK).** `{"log.level":"debug","@timestamp":"2025-08-04T15:03:04.518-0300","message":"HTTP response","http.response.status_code":200,"http.response.body.content":"{\"success\":true,\"data\":{\"token\":\"[REDACTED_JWT_TOKEN]\",\"csrf\":\"[REDACTED_CSRF_TOKEN]\",\"expires\":\"...\"}}"}` **Step 2: Data retrieval request (FAILURE POINT)** **The agent skips the /logs\_query step and incorrectly reuses a stale taskId**. `{"log.level":"debug","@timestamp":"2025-08-04T15:03:04.518-0300","message":"HTTP request","url.original":"https://cloudinfra-gw-us.portal.checkpoint.com/app/laas-logs-api/api/logs_query/retrieve","http.request.method":"POST","http.request.header":{"Authorization":["Bearer [REDACTED_JWT_TOKEN]"]},"http.request.body.content":"{\"pageToken\":\"[REDACTED_PAGETOKEN]\",\"taskId\":\"e86c57dc-cffd-46b1-b5ab-7cff44855cec\"}"}` **Step 2: Retrieval response - FAILURE (404 Not Found).** **The API responds that the resource (the task) could not be found or has expired**. `{"log.level":"debug","@timestamp":"2025-08-04T15:03:05.223-0300","message":"HTTP response","http.response.status_code":404,"http.response.body.content":"{\"success\":false,\"error\":{\"status\":404,\"name\":\"Not Found\",\"details\":[\"Requested resource could not be found or expired\"]}}"}` ### 2. Successful Workflow: `Anti-Bot` Data Stream In contrast, this log from the `Anti-Bot` data stream (from the same agent and policy) shows the correct multi-step API workflow being executed perfectly. **Step 1: Submit a new log query for "Anti-Bot" product.** `{"log.level":"debug","@timestamp":"2025-08-04T15:03:03.802-0300","message":"HTTP request","url.original":"https://cloudinfra-gw-us.portal.checkpoint.com/app/laas-logs-api/api/logs_query","http.request.method":"POST","http.request.header":{"Authorization":["Bearer [REDACTED_JWT_TOKEN]"]},"http.request.body.content":"{\"filter\":\"product:\\\"Anti-Bot\\\"\",\"timeframe\":{\"startTime\":\"...\",\"endTime\":\"...\"}}"}` **Step 1: Response - SUCCESS (200 OK), a fresh taskId is received.** `{"log.level":"debug","@timestamp":"2025-08-04T15:03:04.504-0300","message":"HTTP response","http.response.status_code":200,"http.response.body.content":"{\"success\":true,\"data\":{\"taskId\":\" **REDACTED_TASKID** \"}}"}` **Step 2: Poll the status of the new taskId until "Ready"**. `{"log.level":"debug","@timestamp":"2025-08-04T15:03:06.477-0300","message":"HTTP response","http.response.status_code":200,"http.response.body.content":"{\"success\":true,\"data\":{\"state\":\"Ready\",\"pageTokens\":[\"[REDACTED_PAGETOKEN]\"]}}"}` **Step 3: Retrieve the data using the fresh taskId and pageToken.** `{"log.level":"debug","@timestamp":"2025-08-04T15:03:06.477-0300","message":"HTTP request","url.original":"https://cloudinfra-gw-us.portal.checkpoint.com/app/laas-logs-api/api/logs_query/retrieve","http.request.method":"POST","http.request.header":{"Authorization":["Bearer [REDACTED_JWT_TOKEN]"]},"http.request.body.content":"{\"pageToken\":\"[REDACTED_PAGETOKEN]\",\"taskId\":\"REDACTED_TASKID\"}"}*`\* **Step 3: Response - SUCCESS (200 OK), log records are received**. `{"log.level":"debug","@timestamp":"2025-08-04T15:03:07.685-0300","message":"HTTP response","http.response.status_code":200,"http.response.body.content":"{\"success\":true,\"data\":{\"records\":[{\"product\":\"Anti-Bot\",\"src\":\"[REDACTED_INTERNAL_IP]\",...}],\"recordsCount\":1,\"nextPageToken\":\"NULL\"}}"}` ### Analysis and Conclusion The crucial finding from these logs is the difference in the API workflow. The **`Anti-Bot` data stream works perfectly** : it initiates a new query via `POST /logs_query`, receives a fresh `taskId`, polls the status of that task until it's "Ready", and then successfully retrieves the data with a `POST /retrieve` using the new task details. In stark contrast, the **`antimalware` data stream is flawed** : after authenticating, it completely skips the query and polling steps. It immediately tries to call `POST /retrieve` using a static, stale `taskId` (`e86c57dc-...`) from a previous session. Because this task no longer exists on the Check Point server, the API correctly returns the `404 Not Found` error. Therefore, the evidence strongly suggests this is a state management bug specific to the `antimalware` data stream logic within the integration package (v1.0.0). Other data streams in the same integration are functioning correctly. I hope this detailed analysis is useful for your team. Please let me know if there's anything else I can provide. Best regards, Gustavo