Skip to content
  1. Home
  2. Benchmarks
  3. Integration Bench
rev 01 · preliminary

integration 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.

17 models 10 tasks published in full 170 published attempts 1 official attempt per cell Scorer task-score-v4-mandatory-gatedData 2 Sep 2026

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.

#ModelTask scoreScore barResolvedCost / taskMean timeHarnessStatus
1 Claude Fable 567.6868%$6.6712 minClaude Code
2 GPT-5.6 Sol63.6264%10 minCodex CLI
3 DeepSeek V4 Pro (max)63.3564%$0.2418 minOpenCode
4 Qwen 3.8 2.4T A95B61.6862%$1.2712 minOpenCode
5 Grok 4.661.1862%$0.757 minOpenCode
6 Claude Opus 559.3260%$10.1928 minClaude Code
7 Qwen 3.8 27B (xhigh)57.7358%50 minOpenCode
8 Kimi K357.4758%$1.8635 minOpenCode
9 DeepSeek V4 Flash (max)55.6856%$0.0924 minOpenCode
10 Claude Opus 4.855.5856%$3.9815 minClaude Code
11 Claude Sonnet 553.8554%$3.6414 minClaude Code
12 GPT-5.6 Terra53.7954%8 minCodex CLI
13 Muse Spark 1.253.7054%$1.8124 minOpenCode
14 GPT-5.6 Luna51.7852%10 minCodex CLI
15 GLM 5.2 (xhigh)49.6850%$0.4323 minOpenCode
16 Claude Haiku 4.515.1016%$0.577 minClaude Code
17 Gemini 3.7 Flash35.8536%6 minOpenCode28/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.

Sample task

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.

grading contract
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.

  1. Read the service endpoints and synthetic credentials from the environment and from declared inputs.
  2. Fetch each vendor’s participant documentation, served from the same image as the API.
  3. Authenticate every call. Expect static or rotating credentials, OAuth-like token exchange, and HMAC request signatures.
  4. Walk collections with the pagination style the vendor advertises, not an assumed one.
  5. Persist progress in the vendor’s clock domain, from values the vendor returned.
  6. Make writes idempotent, and honor advertised rate limits, retry rules, and optimistic concurrency.
  7. 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.md for the ticket.
  • repo/ for the starter repository you edit.
  • materials/ and inputs/ 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.yaml when 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:

  1. The entrypoint the harness runs, and its runtime contract.
  2. Input sources, output paths, and output schema.
  3. Ports and service configuration.
  4. Pagination, auth, and retry semantics.
  5. Which timestamps are vendor-owned and which are local.
  6. 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.

staffline
The generated vendor. HMAC auth, a deterministic clock that trails the worker, modification timestamps, and tombstones for deletes.
connector
The starter repository the agent edits. It must backfill, then poll incrementally without duplicating or dropping records.
store
Canonical candidate state after each run. Grading reads this store and the vendor request log.
environment parameters
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

  1. 01 · agent
    Completes the initial backfill
    Claude Sonnet 5 signs requests, walks the candidate collection, and writes the first snapshot. The happy path looks finished.
  2. 02 · agent
    Binds the watermark to local time
    It stores roughly 1.787e12 ms from time.time() as the vendor watermark, instead of the largest upstream mod_ts it actually observed.
  3. 03 · vendor
    Trails the worker clock
    StaffLine data remains near 1.547e12 ms. That future watermark sits ahead of every later update and deletion.
  4. 04 · grader
    Incremental poll skips valid changes
    Two 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.

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.

Coverage

Domains covered.

set / 01
Build
The starter code does not work yet. The agent writes the connector against the vendor's documentation, and finds out the hard way where that documentation is wrong.
grading reads vendor state + request log
Mean Task Score over 16 complete models.
set / 02
Fix
A connector that looks fine ships with planted defects. The agent has to find what is broken and repair it without breaking anything that already worked.
grading reads vendor state
Mean Task Score over 16 complete models.
set / 03
Harden
A connector works on a good day. The agent has to make it survive rate limits, injected faults, forged webhooks, and the retry rules the vendor advertises.
grading reads request log + faults
Mean Task Score over 16 complete models.
set / 04
Migrate
An integration has to move from one vendor to another, matching records across two different schemas without losing or duplicating data.
grading reads record match, two schemas
Mean Task Score over 16 complete models.

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.

100 75–99 50–74 1–49 0 no verdict (provider failure)

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.

task-0001 · StaffLine Sync StaffLine candidates, jobs, applications, and notes into our canonical store polling (pull) · 30 checks 7814 of 17 models resolved task-0011 · — TalentForge connector: consume webhooks while pushing corrections upstream webhooks (push) and writeback (POST/PATCH), across both vendors · 52 checks 00 of 17 models resolved task-0015 · StaffLine Bulk-import a migration batch into StaffLine writeback (bulk create) · 26 checks 61 of 17 models resolved task-0016 · HireWire HireWire connector: push stage-change events + keep an incremental poll fresh writeback (PATCH + POST) and polling (incremental read) · 48 checks 9317 of 17 models resolved task-0020 · GlobalHire Sync GlobalHire candidates into our canonical store (offset polling) polling (pull) · 34 checks 7112 of 17 models resolved task-0025 · CrewCall Reset the CrewCall roster watermark after the tenant rebuild polling · 503 checks 00 of 17 models resolved task-0037 · Placemint Fix the Placemint redeployment sync polling, writeback · 306 checks 8214 of 17 models resolved task-0042 · Rosterly Move the rota mirror onto instant storage polling · 117 checks 7112 of 17 models resolved task-0047 · GlobalHire Reconcile and safely apply the mobility stage repair queue record reads and batch writeback · 100 checks 478 of 17 models resolved task-0049 · Placemint Placemint connector: webhooks, polling, and writeback for a high-volume tenant webhooks (push), polling (pull), writeback (push) · 69 checks 9416 of 17 models resolved
Method

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.

01
The vendors do not exist
Every vendor is generated: a working API simulator with its own auth, pagination, and quirks. Because none of them is real, no SDK, tutorial, or forum answer about them can sit in a model's training data. Nothing here can be solved from memory.
02
The documentation lies on purpose
Each vendor ships docs that are wrong in specific, budgeted ways. An implementation written faithfully from bad documentation is competent code that does not work, and only real traffic reveals it. We measure that gap by running an implementation written exactly to the docs.
03
We try to break our own benchmark
Before a task counts, we grade submissions whose right answer we already know: the gold patch has to score 100, and both an untouched starter and a stub that exits cleanly have to score 0. Starting up, writing empty output, or simply avoiding prohibited behavior can never earn credit.

Method

The construction in one page. The blog post covers the validation work; 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, 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.

Quality control

How a task earns a score.

validation contract / integration bench19 aug 2026
probemethodresult
gold implementationcommitted patch, all public tasksscores 100
unmodified starterno edits, all public tasksscores 0
clean-exit stubruns, writes nothingscores 0
mandatory gate3,390 mandatory checksone failure scores 0
grading isolationfresh vendor stack per gradework state discarded
run provenancedigest-pinned images, SHA-256 evidenceone official attempt per cell
public suite / 5,430 authored checks / 98 scenariospreprint under review
mean task score by integration surface
57.6polling
55.16writeback
20.29webhooks

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.md

Want the full evidence bundle for an attempt, more task samples, or the held-out set? Ask.