Two file operations: put an image into GREM so you can attach it to a listing, and collect the finished output of a tool.
Base URL: https://developers.grem.capital/api/v1.
Upload an image
curl -X POST https://developers.grem.capital/api/v1/uploads \
-H "Authorization: Bearer gsk_live_xxx" \
-F "file=@photo.jpg"
{ "files": [ { "id": "…", "url": "…" } ], "requestId": "req_…" }
Needs the media:write scope. Uploading is not billed.
Limits:
| Parameter | Value |
|---|---|
| Formats | JPG, PNG, WEBP |
| One file | up to 15 MB |
| Files per request | up to 10 |
| Whole request | up to 30 MB |
Field names in the form do not matter - send as many file parts as you like within the limit.
The ids you get back go into the photos field when you create or edit a listing:
{ "photos": ["<first file id>", "<second file id>"] }
The original you uploaded is visible only to you. As soon as the photo is attached to a listing, outside readers are served the watermarked variants only.
Collect a finished result
Tools return file links as relative paths. Download them through the GREM domain with the same key:
curl -H "Authorization: Bearer gsk_live_xxx" \
https://developers.grem.capital/api/v1/artifacts/<path from the response> \
-o presentation.pdf
Needs the tools:artifacts scope. A download is a GET, so it is free and is not counted as an API call.
Partial downloads via the Range header are supported: large videos and presentations can be pulled in chunks or resumed after an interruption.
The key is required here too: an artifact link is not public. Do not embed it in a page your visitors can open - serve the file from your own server instead.
An arbitrary path will not work: only addresses that came out of a tool response are accepted, everything else returns 404.
Related articles
- Tools over the API - what creates these files.
- Objects (read) - the shape of a listing and its photos.
- Errors - the refusal codes.