Imgix

imgix's core model is elegantly simple for agents: image transformations are expressed as URL query parameters. An agent generating responsive images appends ?w=400&h=300&fit=crop&auto=format to any source URL — no API call, no upload, no processing queue. This URL-based approach is uniquely agent-friendly because transformation is stateless and composable. imgix proxies to your origin (S3, GCS, web folder) and applies transformations at the edge. Over 100 transformation parameters cover resizing, cropping, overlays, text rendering, format conversion, and color adjustment. AI-powered features include face detection for smart cropping, dominant color extraction, and object detection. The Management API handles source configuration. For agents generating dynamic visual content, imgix's model eliminates the upload-process-retrieve cycle entirely.

The rendering API is the URL itself — no REST endpoints for transformation. Parameters like w (width), h (height), fit (crop/fill/clip), auto (format/compress), txt (text overlay), mark (watermark), and blend (composition) are appended as query strings. This is powerful because agents can construct transformation URLs without any HTTP client library — string concatenation is sufficient. The Management API at api.imgix.com/api/v1/ covers source creation and configuration, purging cached transformations, and asset management. The rendering parameter space is large (100+ parameters) with well-documented interactions. Signed URLs prevent parameter tampering for public-facing images. Srcset generation helpers in client libraries produce responsive image markup. No batch processing API — each URL is processed on-demand.

Management API uses Bearer token authentication. Rendering URLs are publicly accessible by default — anyone who knows the URL can access the processed image. URL signing uses a per-source token to generate HMAC-signed URLs, preventing unauthorized parameter modification. Signed URLs are critical for agents serving user-generated content — without signing, anyone could modify transformation parameters. The signing mechanism uses MD5-based HMAC with the source's secure URL token. Management API tokens are created in the imgix dashboard — no fine-grained scoping. For agents, the key security decision is whether to enable URL signing on sources that serve dynamic or sensitive content. No OAuth for third-party integrations.

Documentation at docs.imgix.com is excellent — the rendering parameter reference is comprehensive with visual examples showing each transformation's effect. This visual documentation is uniquely valuable for an image processing service. Getting started guides cover source setup and basic transformations. Client libraries for URL generation are available for JavaScript, Python, Ruby, PHP, Java, Go, Swift, and others — these handle URL signing and srcset generation. The sandbox at sandbox.imgix.com allows live experimentation with parameters. The Management API reference is adequate. imgix's blog covers advanced use cases and optimization strategies. For agents, the parameter reference and sandbox are the most valuable resources — they enable experimentation without code.

Rendering errors return HTTP error status codes: 404 for missing source images, 400 for invalid parameter combinations, 502 for origin server errors. The rendering API is stateless and generally reliable — transformations are cached at the edge after first request. Origin errors (source image not found) are the most common failure mode for agents. Invalid parameter values are silently ignored rather than causing errors — this is forgiving but means agents can't validate transformation parameters via error responses. Cache purge via Management API for updated source images. Rate limits on the Management API are documented; rendering has no per-account rate limit but extremely high-volume usage may require enterprise arrangements. Transformation latency on first request depends on source image size and complexity.