Group Webhooks

View as Markdown

Group webhooks let you run every test in a group with one HTTP call. Works with any CI/CD pipeline, deployment tool, or custom automation.

Setup

  1. Open your project → Tests tab.
  2. Expand a group and click the trigger badge (lightning icon).
  3. Toggle Enable webhook on.
  4. Click Save.
  5. Copy the URL - the secret is shown once.

Trigger

$curl -X POST https://tester.army/api/v1/groups/webhook/{id}/{secret}

Enabled tests in the group are queued against the project’s configured URL. Disabled tests are skipped.

Optional body

You can pass JSON to attach commit metadata:

$curl -X POST https://tester.army/api/v1/groups/webhook/{id}/{secret} \
> -H "Content-Type: application/json" \
> -d '{
> "commitSha": "abc123"
> }'

You can also set environment to control how the run appears in the results list:

  • production
  • staging
  • preview

If you pass targetUrl without environment, the run is marked as preview. Use environment: "staging" for staging deployment tests.

$curl -X POST https://tester.army/api/v1/groups/webhook/{id}/{secret} \
> -H "Content-Type: application/json" \
> -d '{
> "commitSha": "abc123",
> "targetUrl": "https://staging.example.com",
> "environment": "staging"
> }'

Mobile app override

You can override the app build used by mobile tests in the group. The build must match the requested run platform (ios or android).

By bundle ID — resolves to the latest uploaded app matching that bundle identifier:

$curl -X POST https://tester.army/api/v1/groups/webhook/{id}/{secret} \
> -H "Content-Type: application/json" \
> -d '{
> "mobile": {
> "bundleId": "com.example.app",
> "buildId": "44"
> }
> }'

By app ID — targets a specific uploaded build by its UUID (returned from the upload API):

$curl -X POST https://tester.army/api/v1/groups/webhook/{id}/{secret} \
> -H "Content-Type: application/json" \
> -d '{
> "mobile": {
> "appId": "<YOUR APP UPLOAD ID>"
> }
> }'

Use appId when multiple builds share the same bundle ID and you need to pin a specific upload.

By remote artifact — provide an HTTPS URL and filename for remote build artifacts:

$curl -X POST https://tester.army/api/v1/groups/webhook/{id}/{secret} \
> -H "Content-Type: application/json" \
> -d '{
> "mobile": {
> "artifactUrl": "https://example.com/builds/MyApp.app.zip",
> "artifactFilename": "MyApp.app.zip",
> "buildId": "eas-982"
> }
> }'

Only one of bundleId, appId, or artifactUrl can be provided per request.

Response

1{
2 "received": true,
3 "status": "queued",
4 "runIds": ["uuid-1", "uuid-2"],
5 "count": 2
6}

When the batch contains iOS tests, the response includes metadata.mobile:

1{
2 "received": true,
3 "status": "queued",
4 "runIds": ["uuid-1", "uuid-2"],
5 "count": 2,
6 "metadata": {
7 "mobile": {
8 "resolvedAppId": "11111111-1111-1111-8111-111111111111",
9 "source": "app_id",
10 "buildId": "44",
11 "temporary": false
12 }
13 }
14}
  • source: "test_default" means each iOS test used its saved app selection.
  • source: "app_id" means the webhook used an already uploaded project app, selected by bundleId or appId.
  • source: "artifact_url" means TesterArmy imported the artifact for this batch.

Artifact-imported apps are temporary. They are removed automatically after every run in the webhook batch reaches a terminal state.

Failure notifications

When a webhook-triggered batch completes and any test fails, TesterArmy sends the failure summary to connected chat providers such as Slack or Discord. If no chat provider delivers, TesterArmy falls back to email.

Batches triggered with commitSha can still report status back through GitHub, but chat notifications remain project-level alerts for the completed batch.

Limits

  • 1 webhook per group. Delete and recreate to regenerate the secret.
  • Subject to your team’s usage limits - returns 429 if exceeded.
  • Webhook must be active (saved) to accept requests. Inactive webhooks return 403.