[
https://issues.apache.org/jira/browse/CAMEL-24673?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18114816#comment-18114816
]
Karol Krawczyk commented on CAMEL-24673:
----------------------------------------
[~fmariani], before writing any code I looked at how this could fit into
camel-openai, and I would like your opinion on the shape.
The SDK side is covered: {{client.webhooks().unwrap(...)}} checks the
{{webhook-id}}, {{webhook-timestamp}} and {{webhook-signature}} headers against
the raw body (5 minute tolerance by default) and returns an
{{UnwrapWebhookEvent}}, or throws {{InvalidWebhookSignatureException}}.
On the Camel side, the closest precedent is camel-whatsapp, camel-clickup and
camel-telegram: the endpoint implements {{WebhookCapableEndpoint}}, and a
webhook processor verifies the request before the route runs. For camel-openai
that would look like:
{code:java}
from("webhook:openai:webhook?webhookSecret={{openai.webhook.secret}}")
.choice()
.when(header("CamelOpenAIWebhookEventType").isEqualTo("response.completed"))
.to("direct:response-completed")
.when(header("CamelOpenAIWebhookEventType").isEqualTo("batch.completed"))
.to("direct:batch-completed")
.end();
{code}
The body would be the parsed event, with the event type, event id and object id
as headers (names are only a proposal).
Why I lean towards this rather than a producer operation or a processor:
* Verification always runs first, on the untouched body. A producer operation
placed after a body conversion would reject every event, and a failed check
would surface as a 500 unless the route maps the exception.
* The handler answers 400 on a missing or invalid signature by itself.
* The secret is mandatory. camel-whatsapp skips verification when no secret is
set; here a missing secret would fail the endpoint at startup instead.
The cost is that camel-openai gets a consumer entry point (through
camel-webhook only, {{createConsumer}} stays unsupported) and a dependency on
camel-webhook. A data format would need changes to the core model, and a plain
processor bean is neither in the catalog nor convenient from YAML, so I left
both out.
Two questions:
# Are you fine with the {{webhook:openai:...}} approach, or would you rather
keep camel-openai producer only, with an operation used after {{platform-http}}?
# {{response.completed}} only carries the response id, so the main use case
needs {{responses-retrieve}} from https://github.com/apache/camel/pull/26264,
which also changes {{OpenAIOperations}}, {{OpenAIEndpoint}} and
{{OpenAIConfiguration}}. Should I wait for it to be merged before opening a PR?
_Reported by Claude Code on behalf of Karol Krawczyk_
> camel-openai: verify and parse OpenAI webhook events
> ----------------------------------------------------
>
> Key: CAMEL-24673
> URL: https://issues.apache.org/jira/browse/CAMEL-24673
> Project: Camel
> Issue Type: New Feature
> Components: camel-openai
> Reporter: Federico Mariani
> Priority: Major
>
> OpenAI notifies webhook endpoints of events such as {{response.completed}},
> {{response.failed}}, {{batch.completed}}, fine-tuning and eval runs, and
> safety alerts. openai-java 4.55 verifies the signature and parses the event
> with {{webhooks().unwrap()}} and {{verifySignature()}}.
> camel-openai is producer only. A helper usable from a {{platform-http}}
> route, such as a processor or a data format configured with the webhook
> secret, would let routes react when background responses (CAMEL-24670) and
> batches finish instead of polling them.
> Split from CAMEL-24671.
> _Claude Code on behalf of Federico Mariani (Croway)_
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
