Arazzo 1.1 workflow for Sume: submit, poll, retry until terminal

Yes, you can describe Sume's submit-then-poll sequence in Arazzo: a sourceDescriptions entry that points at https://api.sume.com/reference/json, a submit step on generateImageV1, and a poll step on getApiJobStatus that fails until terminal is true and has an onFailure retry action. The Arazzo page (read 2026-10-10) shows version 1.1.0, released 17 May 2026.

I checked the field names against the spec and the operationIds against the repo's OpenAPI file, and I parsed the YAML. I did not run an Arazzo runner, so treat the document as a spec-conformant sketch, not a tested pipeline.

The workflow document

Two details are the point. The step outputs use a runtime expression, $response.body#/data/job_id, to carry the job id into the next step's path parameter. And polling is modeled as a failing step: the spec allows retry only as a failure action, with retryAfter and retryLimit, so the poll step's successCriteria says the job is terminal and the retry action fires when it is not.

arazzo: 1.1.0
info: {title: Sume image job, version: 1.0.0}
sourceDescriptions:
  - {name: sume, url: "https://api.sume.com/reference/json", type: openapi}
workflows:
  - workflowId: imageJob
    inputs:
      type: object
      properties: {prompt: {type: string}, key: {type: string}}
    steps:
      - stepId: submit
        operationId: $sourceDescriptions.sume.generateImageV1
        parameters:
          - {name: Idempotency-Key, in: header, value: $inputs.key}
        requestBody:
          contentType: application/json
          payload: {prompt: $inputs.prompt, mode: async}
        successCriteria: [{condition: $statusCode == 202}]
        outputs: {jobId: $response.body#/data/job_id}
      - stepId: poll
        operationId: $sourceDescriptions.sume.getApiJobStatus
        parameters:
          - {name: id, in: path, value: $steps.submit.outputs.jobId}
        successCriteria:
          - condition: $response.body#/data/terminal == true
        onFailure:
          - {name: keepPolling, type: retry, retryAfter: 2, retryLimit: 60,
             criteria: [{condition: $statusCode == 200}]}

Mapping Sume behaviour to Arazzo fields

What Arazzo does not know

The spec has no idea about Sume's next_poll_after_seconds. A fixed retryAfter: 2 is a fallback, and the Sume docs tell clients to obey the hint when it is present, so a runner that can read it from the body is better than one that cannot. The retryLimit of 60 gives roughly two minutes of polling at 2 seconds, which is far too short for a long video job, so size it to the model you call or use a webhook.

A retry action also cannot add an idempotency key, because the key belongs to the submit step, which is not retried here. That is correct: the poll is a read.

When to bother

An Arazzo document earns its place when several teams or tools must agree on a call sequence, for example a docs site, a test generator and a partner integration. For one service calling one endpoint, the loop in your own language is shorter. Keep the document next to the OpenAPI file and review it when the reference JSON changes, because operationId renames break it silently.