stafflineintegration bench
Can a coding agent ship a third-party API integration that survives contact with the vendor? A public task set against 14 synthetic vendors, graded from the vendor's own request logs.
Task score is the mean over the full public set (0 to 100). Resolved is the share of tasks where every mandatory check passed. Click a column to sort; click a model for its per-task breakdown.
Leaderboard
| # | Model | Pass 1 | Resolved |
|---|---|---|---|
| 1 | 69.35±4.38 | 70% | |
| 2 | 67.68±4.72 | 68% | |
| 3 | 65.40±5.12 | 66% | |
| 4 | 63.62±5.14 | 64% | |
| 5 | 63.35±4.91 | 64% | |
| 6 | 62.62±5.36 | 64% | |
| 7 | 61.68±4.57 | 62% | |
| 8 | 61.18±5.48 | 62% | |
| 9 | 59.68±4.83 | 60% | |
| 10 | 59.37±5.63 | 60% | |
| 11 | 59.32±5.07 | 60% | |
| 12 | 57.73±4.46 | 58% | |
| 13 | 57.66±5.22 | 58% | |
| 14 | 57.47±4.96 | 58% | |
| 15 | 57.31±5.41 | 58% | |
| 16 | 55.68±4.68 | 56% | |
| 17 | 53.85±4.88 | 54% | |
| 18 | 53.79±5.33 | 54% | |
| 19 | 53.70±4.54 | 54% | |
| 20 | 51.78±5.58 | 52% | |
| 21 | 49.68±5.86 | 50% |
Read these as development-set numbers. The public set is the tasks the instrument was built and debugged against. Pass 1 is the Task Score of the one published attempt per cell; the ± beside it is half the interval it is expected to move within on re-runs, and hovering it shows the exact bounds. Harnesses differ by model family (Claude Code, Codex CLI, OpenCode). Cost / task is list price times the official attempt's token usage: Anthropic list rates for Claude Code, OpenRouter list rates for Codex CLI and OpenCode. Capability claims wait for the held-out set.
Method
The construction in one page. The blog post covers the validation work, and the vendor classes table maps the fictional systems to familiar product categories. The checked-in evidence for any attempt is one click from its trajectory.
What the agent gets
A ticket (PROBLEM.md), a starter repository, and vendor documentation generated from the same declaration as the vendor simulator. The documentation is wrong in deliberate places. The vendor runs live in the task environment with its own auth chain, pagination, rate limits, webhook semantics and injectable faults.
What is graded
L1, data correctness: the canonical store after the run, checked against an answer key produced by a committed script that talked to the same vendor. L2, protocol discipline: hard and soft checks read from the vendor's request log: credentials never in a query string, advertised retry delays honoured, no full re-crawl on an incremental run, forged webhook signatures rejected. L3, fault survival: whether the integration recovered from faults injected mid-run.
How the score is formed
Scorer task-score-v4-mandatory-gated. Any failed mandatory check zeroes the task; otherwise the task score is the fraction of remaining checks passed, on a 0 to 100 scale. The leaderboard reports the mean over the full public set, with a missing verdict counted as 0. This replaced an earlier dense partial-credit design under which a submission that did nothing scored 22.6.
What is held fixed
Task tree and harness tree hashes, vendor image digests, scorer version, the recorded reasoning effort (shown next to the model name; xhigh or max where the provider exposes it, otherwise the provider default) and a 60-minute wall clock are recorded per attempt in summary.json. Each model runs in its vendor's own harness: Claude Code, Codex CLI, or OpenCode via OpenRouter. Cost / task prices that attempt's token usage at the list rates above.
Incremental candidate sync against a generated vendor
An illustrative task from the public suite. Every vendor in the suite is generated, so the specifics below exist only inside this environment.
- Work type
- Incremental polling against a live vendor
- Documentation
- Sparse. The clock domain is not spelled out as a rule.
- Grading
- Fresh vendor stack. Trusted verifier reads outputs and vendor-owned logs.
Task
Synchronize candidates from StaffLine under HMAC authentication, then capture incremental updates and tombstones. A connector that finishes the initial backfill can still fail if the next poll skips valid changes.
Decisive invariant
- Watermarks stay in the upstream clock domain.
- Inclusive replay of the last observed modification timestamp is safe.
- Tombstones and later updates must land after the first backfill.
Full task text
Your task
Resolve the engineering ticket in PROBLEM.md by producing durable
integration software in the starter repository. Gather context from the
running vendor services before implementing anything.
The vendor services are mandatory. A solution that never puts signed requests on the wire cannot pass, and the services must be reachable from the connector before work begins.
Ticket: Candidate sync against StaffLine drops changes after the first backfill.
Context gathering strategy
Treat the ticket as the requirement, not the wire contract. The contract lives in the vendor’s served documentation and in the responses the vendor actually returns. Documentation in this suite is truthful, stale, or sparse, so any rule the ticket leaves implicit has to be recovered by reading the docs and observing behavior.
Protocol usage
No MCP servers are exposed in this environment. The vendor APIs are the tools. If a harness does front them with MCP, treat it as another transport and keep the wire contract identical.
- Read the service endpoints and synthetic credentials from the environment and from declared inputs.
- Fetch each vendor’s participant documentation, served from the same image as the API.
- Authenticate every call. Expect static or rotating credentials, OAuth-like token exchange, and HMAC request signatures.
- Walk collections with the pagination style the vendor advertises, not an assumed one.
- Persist progress in the vendor’s clock domain, from values the vendor returned.
- Make writes idempotent, and honor advertised rate limits, retry rules, and optimistic concurrency.
- Survive restarts, transient server errors, stale reads, dropped or duplicated events, and cursor or token expiry.
# discover the wire contract
curl -s "$STAFFLINE_URL/_docs/openapi.yaml" -o openapi.yaml
# signed request, then read the vendor's own progress fields
TS=$(date +%s)
SIG=$(printf '%s%s' "$TS" "$REQ_PATH" \
| openssl dgst -sha256 -hmac "$STAFFLINE_SECRET" -r | cut -d' ' -f1)
curl -s "$STAFFLINE_URL$REQ_PATH" \
-H "X-Timestamp: $TS" -H "X-Signature: $SIG" -o page.json
jq '{next: .next_cursor, watermark: ([.items[].mod_ts] | max)}' page.json
Available resources
Inside the participant workspace:
PROBLEM.mdfor the ticket.repo/for the starter repository you edit.materials/andinputs/for task-specific documents and seed data.- Endpoints, synthetic credentials, and auth details in the environment.
- Vendor documentation at
/_docs/, with OpenAPI at/_docs/openapi.yamlwhen the vendor publishes it.
Outside it, and unavailable to you: task.yaml, verifier/, authoring/,
fixtures, the gold patch, vendor source, and the fault schedule.
Vendor-specific instructions
Only the services in this task’s stack exist. There is no shared world, and no vendor here has a public counterpart to recall.
StaffLine
Candidate system of record. Collection reads, an incremental feed carrying
modification timestamps, and tombstones for deletes. HMAC signatures on
every request. Documentation at $STAFFLINE_URL/_docs/. Its deterministic
clock trails the worker’s wall clock.
Canonical store
The connector’s own durable state, read directly by grading. Records must match StaffLine after the backfill, later updates, and deletions.
Solution requirements
Gather the vendor’s state and behavior first, then implement. The connector must run end to end from a cold start: backfill, persist a watermark, and pick up later changes on the next poll without duplicating or dropping records.
Critical: read the vendor before coding
The ticket is a symptom report, not a full brief. Before writing the fix, establish from the docs and observed responses:
- The entrypoint the harness runs, and its runtime contract.
- Input sources, output paths, and output schema.
- Ports and service configuration.
- Pagination, auth, and retry semantics.
- Which timestamps are vendor-owned and which are local.
- Acceptance behavior across a restart.
Do not guess a requirement the vendor can answer.
Naming rule
Keep the entrypoint the starter repository declares, at the path
PROBLEM.md specifies. If neither names one, leave the starter entrypoint
in place and make it executable.
Final deliverable
A working connector in the captured workspace. Grading restarts the vendor stack from a checkpoint and runs your artifact against it, so a process you left running, exploration notes, plans, or hand-written output files do not count as completion. Any failed mandatory check gates Task Score to zero.
Grading
- Artifact, not a live process mandatoryGrading starts a fresh vendor stack. Work-phase state cannot help the candidate.
- Final state mandatoryCanonical candidate records match StaffLine after backfill, later updates, and tombstones.
- Upstream clock domain mandatoryThe incremental watermark is the largest vendor modification timestamp actually observed, never worker wall time.
- Protocol conduct mandatoryEvery request carries a valid HMAC signature. Credentials are not leaked into outputs or logs.
- Inclusive replay partialRe-reading the last observed mod_ts boundary is safe and does not duplicate or drop rows.
- Authored extras partialLower-weight checks can fail after the mandatory gate. Task Score is still non-zero if every mandatory check passes.
Unit tests
test_hmac_on_every_requestRequest log contains a valid HMAC for each StaffLine call.test_backfill_completenessAfter the first run, every seeded candidate is present in canonical state.test_watermark_uses_vendor_mod_tsStored watermark stays inside the vendor clock domain (~1.547e12 ms), not time.time().test_incremental_updates_applyTwo later updates and one new candidate land on the second poll.test_tombstone_deletesA deletion that appears only as a tombstone is reflected in canonical state.test_no_skipped_changes_after_backfillA future watermark does not exclude valid upstream changes.test_fresh_stack_replayThe captured workspace still passes when the vendor is restarted from a checkpoint.test_mandatory_gateAny failed mandatory check forces Task Score to 0, even if other checks pass.
Environment
The agent gets a running StaffLine service rather than a description of one. The vendor is a real HTTP service holding real state. Its documentation is served from the same image as the API.
connectorstore- Auth
- HMAC request signatures on every call.
- Clock
- Vendor mod_ts near 1.547e12 ms. Worker wall clock near 1.787e12 ms.
- Incremental
- Watermark must be the largest modification timestamp actually observed.
- Deletes
- Tombstones in the incremental feed. Archived candidates are never dropped silently.
Trajectory
- 01 · agentCompletes the initial backfillClaude Sonnet 5 signs requests, walks the candidate collection, and writes the first snapshot. The happy path looks finished.
- 02 · agentBinds the watermark to local timeIt stores roughly 1.787e12 ms from time.time() as the vendor watermark, instead of the largest upstream mod_ts it actually observed.
- 03 · vendorTrails the worker clockStaffLine data remains near 1.547e12 ms. That future watermark sits ahead of every later update and deletion.
- 04 · graderIncremental poll skips valid changesTwo updates, one new candidate, and a tombstone never reach canonical state. A mandatory check fails, so Task Score is gated to zero.
Result: not solved. Sonnet 5 scores 0.00 on this task. Claude Fable 5.1 and Claude Fable 5 score 100.00 on the same ticket by advancing progress from the largest modification timestamp actually observed. All three implementations reach the happy path. The split is the source of progress: an integration watermark is vendor state, not worker time.
By integration surface
Each ticket declares the surface it exercises. Groups are non-exclusive: a task that polls and writes back counts toward both. Webhook tasks need a long-running receiver, signature verification, ordering, deduplication and deletion recovery, and they separate models far harder than the top of the leaderboard does.
| Model | polling | writeback | webhooks |
|---|---|---|---|
| Claude Fable 5.1 | 76 | 71 | 44 |
| Claude Fable 5 | 76 | 71 | 36 |
| GPT-6 Astra | 69 | 75 | 26 |
| GPT-5.6 Sol | 69 | 71 | 18 |
| DeepSeek V4 Pro (max) | 71 | 71 | 35 |
| Tencent HY 4 Preview | 66 | 56 | 26 |
| Qwen 3.8 2.4T A95B | 69 | 71 | 26 |
| Grok 4.6 | 68 | 65 | 35 |
| Gemini 3.8 Flash | 64 | 62 | 27 |
| GLM 5.3 Flash | 68 | 61 | 35 |
| Claude Opus 5 | 63 | 66 | 26 |
| Qwen 3.8 27B (xhigh) | 62 | 62 | 18 |
| Muse Spark 1.3 | 61 | 66 | 18 |
| Kimi K3 | 61 | 66 | 17 |
| GLM 5.3 | 62 | 61 | 26 |
| DeepSeek V4 Flash (max) | 62 | 57 | 18 |
| Claude Sonnet 5 | 57 | 57 | 9 |
| GPT-5.6 Terra | 57 | 66 | 18 |
| Muse Spark 1.2 | 59 | 52 | 18 |
| GPT-5.6 Luna | 54 | 57 | 9 |
| GLM 5.2 (xhigh) | 52 | 57 | 0 |
Domains covered.
Every model on every task
21 models by the 50 public tasks, columns easiest first. Switch the corner control to read them in published order. Each cell is one recorded run; click it to open the trajectory.
The 50 public tasks
Each task is a ticket against one synthetic vendor. Mean score and the number of models that resolved it show how much the task discriminates: a task everyone or no one solves contributes nothing to a ranking.
How we built it.
Integration work is where agent coding claims meet production reality: undocumented API behavior, stateful external systems, and correctness that only shows up when the data actually arrives where it should. Integration Bench evaluates agents against a live, containerized applicant tracking system simulator, not a frozen repository.
How a task earns a score.
| probe | method | result |
|---|---|---|
| gold implementation | committed patch, all public tasks | scores 100 |
| unmodified starter | no edits, all public tasks | scores 0 |
| clean-exit stub | runs, writes nothing | scores 0 |
| mandatory gate | mandatory checks across all public tasks | one failure scores 0 |
| grading isolation | fresh vendor stack per grade | work state discarded |
| run provenance | digest-pinned images, SHA-256 evidence | one official attempt per cell |
Published models. Webhook tasks need a long-running receiver, signature verification, ordering, deduplication, and deletion recovery, so they separate models harder than the top of the leaderboard does.
Early findings
Claude Fable 5.1 leads at 69.35 Task Score, with 35 tasks resolved. The next four are Claude Fable 5, GPT-6 Astra, GPT-5.6 Sol, and DeepSeek V4 Pro (max). No model resolves more than 70% of the suite.
The larger gap is the work itself. Webhook tasks average 23.15 across the current rows, against 64.03 for polling and 63.76 for writeback. Agents are stronger at conventional data pulls than at keeping an integration coherent across events, faults, and more than one source of truth.
Use the data
Everything on this page is rendered from static JSON you can fetch directly. The same files are also exposed at https://data.integrationbench.com/v1/integration-bench/manifest.json for scripts.
https://www.integrationbench.com/data/v1/integration-bench/manifest.json models, tasks, counts
https://www.integrationbench.com/data/v1/integration-bench/leaderboard.json one row per model
https://www.integrationbench.com/data/v1/integration-bench/matrix.json model × task scores
https://www.integrationbench.com/data/v1/integration-bench/models/{model}.json
https://www.integrationbench.com/data/v1/integration-bench/tasks/{task}.json
https://www.integrationbench.com/data/v1/integration-bench/attempts/{model}/{task}/
summary.json · trajectory.json · verdict.json
vendor-requests.json · transcript.jsonl · patch.diff · problem.mdWant the full evidence bundle for an attempt, more task samples, or the held-out set? Ask.