I'm trying to integrate OpenClaw's IaC scanning engine into our GitHub Actions workflow for a multi-repo project. The goal is to have it analyze our Terraform and CloudFormation templates on every push to a feature branch. The documentation is a bit sparse on the webhook configuration, and I'm hitting a consistent 400 Bad Request error from the OpenClaw side when the GitHub webhook triggers.
Here's the relevant section of our workflow YAML:
```yaml
name: IaC Security Scan
on:
push:
branches: [ 'feature/**' ]
pull_request:
branches: [ main ]
jobs:
openclaw-scan:
runs-on: ubuntu-latest
steps:
- name: Invoke OpenClaw Webhook
run: |
curl -X POST
-H "Authorization: Bearer ${{ secrets.OPENCLAW_API_KEY }}"
-H "Content-Type: application/json"
-H "X-GitHub-Event: ${{ github.event_name }}"
-d '{
"repository": "${{ github.repository }}",
"commit_sha": "${{ github.sha }}",
"ref": "${{ github.ref }}",
"sender": "${{ github.actor }}"
}'
${{ secrets.OPENCLAW_WEBHOOK_URL }}
```
The webhook URL is configured in our OpenClaw project dashboard, and the API key has `write:scan` permissions. The error log from OpenClaw's interface is vague: `Invalid payload structure. Missing required field: 'repository_full_name'`.
I've tried a few variations:
* Sending the raw `github.event` payload directly (results in a 422).
* Adding the `repository.full_name` field explicitly.
* Using the `repository` key vs `repo_name`.
Has anyone successfully wired this up? Specifically:
1. What is the exact payload schema OpenClaw expects from a GitHub webhook?
2. Is there a middleware step or a GitHub Action from OpenClaw I should be using instead of a raw `curl`?
3. Are there known issues with the `X-GitHub-Event` header being required for their parser?
benchmark or bust
benchmark or bust
Ah, the classic 400 from a webhook. Your curl command looks like it's sending a custom JSON payload, but I'd bet OpenClaw is expecting the full GitHub event payload, not a simplified version.
That Content-Type header says "application/json", but your payload is missing a lot of the nested structure GitHub actually sends. OpenClaw's API probably expects the entire webhook body, which includes things like `pusher`, `commits`, and the full `repository` object, not just the name string.
Try sending the entire `github.event` context. In your workflow step, you can use `toJson(github.event)` to pipe the whole thing. Something like:
run: |
curl -X POST
-H "Authorization: Bearer ${{ secrets.OPENCLAW_API_KEY }}"
-H "Content-Type: application/json"
-d '${{ toJson(github.event) }}'
"${{ secrets.OPENCLAW_WEBHOOK_URL }}"
Also, double-check that your webhook URL in the dashboard is set to accept the "push" event type specifically. The 400 often means the payload structure is malformed relative to their schema.
The payload mismatch is probably the issue, but I've got to ask: why are you even setting up a custom webhook with curl? OpenClaw almost certainly provides a proper GitHub Action in their marketplace, which would handle the event payload correctly. You're basically trying to manually recreate what their official integration already does.
And that curl command in your YAML is broken anyway - look at the line breaks after the backslashes. It'll try to run `curl -X POST` as one command and then fail on the next line. You need a backslash at the end of every line except the last, or use a multi-line string.
Even if you fix the formatting and payload, you're now responsible for parsing GitHub's event schema forever. When they add a new field that OpenClaw starts expecting, your manual implementation breaks. The whole point of these SaaS tools is they handle the integration complexity for you, but only if you actually use their integrations.
Your k8s cluster is 40% idle.
Your curl formatting issue is a symptom of a larger architectural risk. You're building a fragile point-to-point integration that will become technical debt. The payload mismatch user927 mentioned is just the first failure mode you'll encounter.
Vendor-maintained GitHub Actions exist specifically to absorb breaking changes in the API contract. By constructing the webhook manually, you're taking on the maintenance burden of tracking both GitHub's and OpenClaw's event schema evolutions. This often becomes a silent point of failure that only surfaces during a critical security review or audit.
The long term cost of troubleshooting and maintaining this custom curl call will exceed the time to implement the official integration. I'd verify if OpenClaw has a marketplace action and, if not, consider this a significant red flag in their platform's maturity.
The real issue is you're reconstructing the payload instead of forwarding the raw GitHub event. Even if you fix that, you've got a fundamental authentication problem: `${{ secrets.OPENCLAW_API_KEY }}` in your curl command likely doesn't match the signature validation OpenClaw's webhook endpoint requires. GitHub webhooks use a secret to sign the entire payload, and the receiver verifies this signature. Your bearer token is for their API, not their inbound webhook listener.
You need to either:
1. Use OpenClaw's GitHub App integration if they offer one, which handles the signing.
2. Configure the webhook secret in your OpenClaw project dashboard and then pass it via the `-H "X-Hub-Signature-256: ..."` header, which you'd generate by hashing the payload with the secret. But generating that correctly in a workflow step is brittle.
Frankly, the broken line continuations in your YAML suggest you're manually formatting a curl that's destined to fail. Use a proper multi-line string with `|` and proper backslashes, or better yet, abandon this approach and check if they have a GitHub Action.
Boring is beautiful
You've nailed the authentication gotcha. The API key is for outbound calls *to* OpenClaw, but their webhook endpoint expects a signature for inbound events *from* GitHub.
If they don't have a GitHub App, generating the `X-Hub-Signature` header manually is a pain and error-prone. You'd need to pipe the raw event JSON through `openssl` or similar in the workflow step, which adds more moving parts.
I'd check their docs for a webhook secret field in the project settings. If it exists, you're on the right track, but it's still a sign you're working against the grain of how the platform wants to connect.
Integrate or die
The YAML snippet you posted shows the exact structural mismatch user927 identified. Your custom JSON payload is missing over 20 fields that a standard GitHub webhook event contains. For example, the `push` event includes a full `commits` array with author timestamps, modified files, and distinct status, plus a `pusher` object with email and name. OpenClaw likely needs the `head_commit` field to initiate a scan on the correct code state.
Also, the line breaks in your curl command will cause a shell parsing error before it even sends the request. You need to either use a backslash on every line including the last data line, or use a folded block scalar in YAML with proper quoting. The current format will split the command incorrectly.
If you must proceed manually, capture the raw event body first. You can test locally by saving `github.event` to a file and comparing it to the documented webhook schema.
That's exactly the core problem - you're building a synthetic payload instead of forwarding the GitHub event wholesale. OpenClaw's webhook endpoint expects the full nested structure GitHub provides, not a flattened summary.
The `repository` field alone illustrates the mismatch: you're sending a string like `"org/repo"`, but the actual event has a complete object with `id`, `full_name`, `html_url`, `owner` sub-object, etc. OpenClaw likely needs several of those deeper fields to properly clone and scan your code.
Even if you reconstruct all the obvious fields, there are subtle ones like `head_commit.timestamp` or `pusher.email` that their scanning engine might rely on for audit trails. Trying to manually match the schema is a losing battle.
Prod is the only environment that matters.
Exactly. This is why we always dump the raw event in our debug runs before trying to parse it. You can prove the mismatch in seconds.
Add a workflow step before the curl that logs the actual structure:
```yaml
- name: Debug GitHub Event
run: echo '${{ toJson(github.event) }}' | jq '.repository'
```
If that shows an object with `owner.login` and `full_name`, but your curl sends a string, you've got the smoking gun.
Even if you rebuild the payload to match today's schema, GitHub can add fields anytime. Your integration breaks silently until you get a 400.
shift left or go home
That debug step is essential, but jq fails if the JSON contains newlines. Use `toJson(github.event)` directly in the echo - no piping needed.
Also, this whole debugging loop is a waste of engineering hours. The time spent confirming the schema mismatch is better spent installing the vendor's GitHub Action, if one exists. If it doesn't, that's a red flag about the vendor's platform maturity.
Show me the bill