# call_method

> Source: https://docs.clonepartner.com/reference/steps/call-method/

<!-- sources: src/steps/call-method-step.ts, src/steps/base-step.ts, src/steps/types.ts, references/envoy/streaming.md, references/envoy/step-types.md -->

# call_method

Calls a method on a Connector and emits the result downstream — the primary step for all I/O.

## When to use it

Use `call_method` whenever a step needs to read from or write to a Connector: as the pipeline source (`read`, `find`, `list`) or as a per-item write (`create`, `update`, `upsert`). When you need to call a connector per item and keep the original item's fields, use the `$callMethod` JSONata function inside a [transform](/reference/steps/transform/) instead — but only for bounded lookups such as `find_one` or `count`, because `$callMethod` buffers its entire result into memory.

## Configuration

| Key | Type | Required | Default | Description |
|---|---|---|---|---|
| `connector` | string | Yes | — | Connector slot name from the task's `connectors`. |
| `method` | string | Yes | — | Method name; depends on the connector type. Validation checks it against the connector's method schemas. |
| `args` | object | No | `{}` | Arguments passed to the connector method. |

Any other key in the config produces the validation warning `Unknown key '<key>' in call_method config`.

## Example

```yaml
name: fetch-tickets
connectors:
  source:
    type: freshdesk
  destination:
    type: sqlite
steps:
  - name: list_tickets
    type: call_method
    config:
      connector: source
      method: list
      args:
        resource: tickets

  - name: save_ticket
    type: call_method
    config: |
      {
        "connector": "destination",
        "method": "upsert",
        "args": { "table": "tickets", "data": input, "conflict_columns": ["id"] }
      }
```

The first step uses a static config because it references nothing from the stream. The second uses a JSONata string config (`config: |`) because it references `input`.

## Behavior notes

- **Array results stream with backpressure.** When the method returns an array or an async iterable, each element is emitted downstream as a separate item. Async iterables are consumed lazily, so a slow downstream step pauses the source instead of buffering pages in memory.
- **The return value replaces the input item.** After a `call_method` step, `input` for the next step is the method's result — the incoming item's fields are gone. Carry needed fields forward in a prior `transform` and read them via `steps.<name>.output`.
- **Return-value contract:** `undefined` or an empty array drops the item; a non-empty array fans out; anything else is emitted as a single item.
- **A config that evaluates to `null` or `undefined` passes the input through unchanged** — the item is not dropped.
- The task's abort signal is passed to the connector call, so stopping a run cancels in-flight requests.

## Related

- [transform](/reference/steps/transform/) — shape results, or enrich per item with `$callMethod`
- [Task YAML schema](/reference/task-yaml/) — shared step keys like `concurrency` and `error_handling`
- [Reading and writing data](/building/reading-and-writing-data/) — source and write patterns with `call_method`