Skip to content

Export things back out

A catalog you cannot get out of is a trap. export_things copies the bytes behind matching things into a storage resource, and it is the reverse of a sync in every respect that matters.

{
"name": "export_things",
"arguments": {
"destination_id": "...",
"query": "invoice",
"kind": "pdf",
"since": "2024-01-01"
}
}

destination_id defaults to this tenant’s default storage if you leave it off.

Same fields, same meaning — one grammar covers a search query, an export’s source, and a rule’s matcher:

Field Restricts to
query words to match
kind one kind
resource_id things from one resource
folder a prefix of the locator key, as a folder: 2024/invoices
since / before when the thing was catalogued

A copy is written as another reference to the thing it came from, not as a new thing. Two consequences:

  • A thing already written to the destination is left alone, so re-running an export resumes rather than duplicates.
  • The exported copy is findable. It is the same thing, now living in one more place.

Like every operation over an unbounded number of things, an export checkpoints through job-iteration. An export interrupted by a deploy carries on at its cursor. Watch it with list_runs and stop it with cancel_run:

{ "name": "list_runs", "arguments": { "kind": "export" } }

Cancelling sets a flag the iteration reads on its next check rather than killing anything — the work stops within a few dozen objects, and whatever was already copied stays copied and catalogued.

The sync/export family is one shape with the endpoints swapped, and the flag is what separates them:

source destination make it a thing is
Drive ingest — references only
Drive B2 backup
Drive default storage ingest + materialize
things matching q B2 export

The catalog is never a destination; cataloguing is a flag. See The four movements.

Once the bytes are somewhere you control, forgetting the reference and deleting the object are still two different operations — and the default is forget. See Things.