stafflineintegration bench
Can a coding agent ship a third-party API integration that survives contact with the vendor? A public task set against 15 invented vendors, graded from the vendor's own request logs.
Leaderboard
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.
| # | Model | Task score | Score bar | Resolved | Status |
|---|---|---|---|---|---|
| 1 | 67.68 | 68% | |||
| 2 | 63.62 | 64% | |||
| 3 | 63.35 | 64% | |||
| 4 | 61.68 | 62% | |||
| 5 | 61.18 | 62% | |||
| 6 | 59.32 | 60% | |||
| 7 | 57.73 | 58% | |||
| 8 | 57.47 | 58% | |||
| 9 | 55.68 | 56% | |||
| 10 | 55.58 | 56% | |||
| 11 | 53.85 | 54% | |||
| 12 | 53.79 | 54% | |||
| 13 | 53.70 | 54% | |||
| 14 | 51.78 | 52% | |||
| 15 | 49.68 | 50% | |||
| 16 | 15.10 | 16% | |||
| 17 | 35.85 | 36% | 28/50 graded |
Read these as development-set numbers. The public set is the tasks the instrument was built and debugged against. Run-to-run variance is not characterised (one attempt per cell), harnesses differ by model family (Claude Code, Codex CLI, OpenCode), and Codex CLI does not report cost. Capability claims wait for the held-out set.
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 scores 100.00 on the same ticket by advancing progress from the largest modification timestamp actually observed. Both implementations reach the happy path. The split is the source of progress: an integration watermark is vendor state, not worker time.
| Model | polling | writeback | webhooks |
|---|---|---|---|
| Claude Fable 5 | 76 | 71 | 36 |
| GPT-5.6 Sol | 69 | 71 | 18 |
| DeepSeek V4 Pro (max) | 71 | 71 | 35 |
| Qwen 3.8 2.4T A95B | 69 | 71 | 26 |
| Grok 4.6 | 68 | 65 | 35 |
| Claude Opus 5 | 63 | 66 | 26 |
| Qwen 3.8 27B (xhigh) | 62 | 62 | 18 |
| Kimi K3 | 61 | 66 | 17 |
| DeepSeek V4 Flash (max) | 62 | 57 | 18 |
| Claude Opus 4.8 | 61 | 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 |
| Claude Haiku 4.5 | 18 | 19 | 23 |
15 fictional vendor systems, 98 scenarios.
Every attempt
17 models by the 10 tasks published so far. Each cell is one recorded run; click it to open the trajectory. The rest of the public set is released in batches.
The 10 public tasks
Each task is a ticket against one invented 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.
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, reasoning effort (xhigh where the provider exposes it) 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.
| 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 | 3,390 mandatory checks | 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 |
Sixteen complete 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 leads at 67.68 Task Score, with 34 tasks resolved. GPT-5.6 Sol and DeepSeek V4 Pro follow at 63.62 and 63.35. No complete model resolves more than 68% of the suite.
The larger gap is the work itself. Webhook tasks average 20.29 across complete rows, against 57.60 for polling. Sparse-documentation tasks trail truthful-documentation tasks by 23.64 points. 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/ 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.