Attach a context image to segments

Attaches the context image identified by the given ID to the given segments and to the segments found from rendered strings. The image is attached to each segment's text in the image's language; segments must belong to the project's stack and have a text in that language. A segment that is already attached keeps its link and a SUGGESTION becomes an attachment, so the operation is idempotent. A segment given with highlights gets exactly those highlights. If a newly attached segment exceeds the plan's per-segment context-image limit, its oldest attachment — possibly of another context image — is evicted to make room. Returns the full updated context image; list the links with listContextImageSegments. Requires project-level context-image management permission.

Recent Requests
Log in to see full request history
TimeStatusUser Agent
Retrieving recent requests…
LoadingLoading…
Path Params
string
required
^ci_[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}$

Unique identifier of the context image.

Body Params

Request body to attach a context image to segments, given directly or found from rendered strings.

segments
array of objects | null

Segments to attach the context image to, each optionally with its highlights. A segment that is already attached keeps its link and gets the given highlights; a SUGGESTION becomes an attachment. Each segment may appear only once.

segments
rendered_strings
array of objects | null

Rendered strings with candidate SDK keys and pixel bounds; resolved on the image language's branch.

rendered_strings
boolean | null

Whether exact text fallbacks of rendered strings become TEXT_BASED links. Defaults to false; ambiguous keys always remain suggestions.

Headers
string
length between 1 and 255

Optional unique key for best-effort POST retry protection. Redis reserves the key, the request runs with ordinary service transactions, then the successful response is cached separately for 24 hours by default. There is no request-wide transaction or atomic commit between the operation and its replay result. A matching cached response is replayed verbatim with Idempotent-Replayed: true. Redis loss/eviction or retention expiry can remove protection and allow re-execution. Uploads and chunked bodies are covered; multipart boundaries and JSON property order may differ. Retries still pass validation and current authorization; a later 403/404 does not undo the original operation. A changed payload returns 422 idempotency_key_mismatch. A recent active reservation returns 409 idempotency_key_in_use with Retry-After. A retry with an unresolved key, including an unfinished reservation older than 5 minutes, returns 409 idempotency_outcome_unknown without Retry-After. This timeout does not release the reservation or permit re-execution while it is retained. Inspect the affected resource before starting a new operation; do not blindly reuse an unresolved key after expiry. A 4xx rejection releases the reservation, allowing the same key to be retried after correcting the cause. A 5xx or interruption after execution starts leaves it unresolved. An unavailable reservation store returns 503 before execution; an oversized request returns 413. Cache-save failure or a response over the cache limit preserves the original success status, headers and body; only future retries become unresolved. When idempotency is explicitly disabled by server configuration, the header is ignored and requests execute normally without retry protection. Use a new unique key for each intended operation.

string
enum
Defaults to application/json

Generated from available response content types

Allowed:
Responses

Language
Credentials
Bearer
LoadingLoading…
Response
Click Try It! to start a request and see the response here! Or choose an example:
application/json
application/problem+json