oto_upload_url
Get a signed, single-use URL to push a big file into oto without passing it through the conversation. With a shell: curl -X PUT --data-binary @FILE '<url>'. Without one, give the URL to the user: it opens an upload form. If the file is already reachable (a link, a Drive file, a project file, a Gmail attachment), use oto_import instead: the server fetches it — as for a file you produced up to 256 KB ({kind:"content"}). Targets: datastore (CSV or NDJSON rows; key designates rows by that column), doc, project_file, image (public permanent URL, 2 MB). With neither a shell nor a user, send rows inline with data_write. The URL is signed, not encrypted: keep confidential names out of it.
Tool call template
Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.
{
"id": 1,
"jsonrpc": "2.0",
"method": "tools/call",
"params": {
"arguments": {
"target": "<target>"
},
"name": "oto_upload_url"
}
}Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| op | No | create | |
| key | No | datastore: the column that DESIGNATES rows — an existing key value modifies its row, a new one creates it, no `upsert` needed. Omitted: the file matches on the table's declared key but ADDS (an existing value follows `upsert`). | |
| _org | No | ||
| kind | No | ||
| title | No | ||
| doc_id | No | ||
| format | No | ||
| target | Yes | ||
| upsert | No | `true` = MERGE when the key value already exists — for a write that ADDS (neither `id` nor `key=`), and for rows of one call that share a key value. A write that designates by `key=` needs no `upsert`. Every merge of a batch comes back in `fusions`. Without it, an adding write on an existing key, or two rows of one call on the same key, is REFUSED (`business_key_exists`). Refused on a table with no business key: there is nothing to merge on. | |
| filename | No | ||
| datastore | No | ||
| parent_id | No | ||
| project_id | No | ||
| description | No | ||
| content_type | No | ||
| origine_override | No | `origine_override=true` states that this call sets the `origine` layer (the value at the START, at import time) knowingly. Without it, writing an origin is refused. ⚠️ Nothing captures an origin automatically any more: `origine: "system"` was REMOVED on 2026-09-08, so writing the value alone keeps nothing — an overwrite is final. For a real IMPORT, prefer `donnees_d_origine=true`, which writes both versions — the current value and the origin — in the same gesture, at the moment the value enters. This parameter only says "I know I am setting that layer", and it applies to this call only. A cell without an `origine` layer has no known starting value: the absence of the layer says so, never a text in its place. | |
| donnees_d_origine | No | `donnees_d_origine=true` sets the FIRST version of the data (the origin) and marks the write as an import in the journal: this call brings data AS THE CLIENT HANDED IT OVER. Each cell gets its `origine` version frozen at the same time as its current value, carrying the same layers: put the provenance in `<field>.comment` and it lands in both. Use it for the import itself, NOT for enrichment — what an agent establishes is the current version. An origin already set is never overwritten (a re-import updates the current version and leaves the origin alone), and an empty cell gets nothing: the client handed over nothing there, which is not the same as handing over an empty value. |