All integrations

imgix

DEVELOPER · DEVELOPER

Sources, assets and CDN purges for the imgix account that person connected.

Connecting imgix in practice

imgix’s Management API limits are per operation class and they are low: 4 requests a second by default, 60 Source creates or updates an hour, 10 asset reads a second and 2 uploads a second, with purge the outlier at 20 a second. Reconfiguring a large number of Sources is therefore a multi-hour job by design.

Scopes that draw scrutiny

  • Account Admin Full access to the account — the widest of the five API key permission levels, and the one that should never be what an agent holds.
  • Sources Creates and manages Sources, which is to say it changes where imgix pulls original images from.
  • Purge Cache management. Cheap to call, globally visible, and the fastest way for an agent to move load onto the origin.
  • Asset Manager Browse / Asset Manager Edit Split read and write over the asset library, so browsing can be granted without editing.
  • Analytics Report data access only — the narrowest level, and enough for most reporting agents.

Rate limits

  • Default: 4 requests per second.
  • Source create and update: 60 per hour.
  • Assets: 10 GET requests per second; 10 refreshes per minute.
  • Upload: 2 per second. Purge: 20 per second.
  • Exceeding any of these returns 429 Too Many Requests; premium customers negotiate custom limits.

Worth knowing

  • Up to 20 API keys per account, each pinned to one permission level, so least privilege is achieved by issuing more keys rather than by scoping one.
  • The source ID is a 24-character string you have to read out of the dashboard URL or the source configuration page — it is not returned by anything an agent would naturally call first.
  • Responses are JSON:API documents, so everything is nested under data/attributes rather than being the flat JSON most clients assume.
  • Errors carry a unique request id that imgix support asks for, which is worth logging alongside the status code.

Checked against Management API (2026-09-29)

Acts as the person, not as itself

Each user connects their own account. Every call carries both identities — the agent and the person it is acting for — so the agent can never reach past what that individual can already do.

Credentials never touch the agent

Tokens live in the vault and attach server-side at call time. The agent holds a session, not a secret, and revoking access does not mean rotating a key.

Every call on the record

Who asked, which agent acted, which action ran, and the verdict that let it through — one audit trail across every integration, not one per vendor.

What an agent can do

Each action is granted on its own. An agent allowed to read is not thereby allowed to write, and the scope beside each row is what the acting user must have connected for it to run at all.

imgix_delete_api_v1_sources_by_source_id_upload_sessions_cancel_by_session_idWRITE

Cancel an open upload session by its id and discard whatever it had received via DELETE /api/v1/sources/{source_id}/upload-sessions/cancel/{session_id}

asset_manager_edit
imgix_get_api_v1_reportsREAD

List the account's generated reports -- CDN logs, image analytics, source analytics, credit analytics and error reports -- with paging, sorting and field filters via GET /api/v1/reports

analytics
imgix_get_api_v1_reports_by_report_idREAD

Read one generated report by id, including whether it has completed and the files it produced via GET /api/v1/reports/{report_id}

analytics
imgix_get_api_v1_sourcesREAD

List the imgix Sources on the account, with JSON:API sparse fieldsets, page-number paging, sorting by name, enabled or deploy date, and field filters via GET /api/v1/sources

sources
imgix_get_api_v1_sources_by_source_idREAD

Read one imgix Source by id, including its deployment settings and deployment status via GET /api/v1/sources/{source_id}

sources
imgix_get_api_v1_sources_by_source_id_assetsREAD

List the Asset Manager contents of one Source, with cursor paging, sparse fieldsets, sorting by creation date, modification date or file size, and field filters via GET /api/v1/sources/{source_id}/assets

asset_manager_browse
imgix_get_api_v1_sources_by_source_id_assets_by_origin_pathREAD

Read one asset's Asset Manager record by its origin path -- dimensions, content type, colours, tags, categories, custom fields and, for video, transcode status via GET /api/v1/sources/{source_id}/assets/{origin_path}

asset_manager_browse
imgix_get_api_v1_sources_by_source_id_upload_sessions_status_by_session_idREAD

Read the state of one upload session by its id via GET /api/v1/sources/{source_id}/upload-sessions/status/{session_id}

asset_manager_browse
imgix_patch_api_v1_sources_by_source_idWRITE

Update an imgix Source's name, enabled flag, deployment settings or upload credentials. Setting enabled to false stops the Source serving images via PATCH /api/v1/sources/{source_id}

sources
imgix_patch_api_v1_sources_by_source_id_assets_by_origin_pathWRITE

Update an asset's name, description, categories, tags or custom fields in the Asset Manager. This edits imgix's metadata record, not the bytes at the origin via PATCH /api/v1/sources/{source_id}/assets/{origin_path}

asset_manager_edit
imgix_post_api_v1_publishWRITE

Make assets available to be served from their Source via POST /api/v1/publish

asset_manager_edit
imgix_post_api_v1_purgeWRITE

Remove one image URL from imgix's CDN cache so the next request re-fetches it from the origin. Purging is asynchronous and applies to the exact URL given (or, with sub_image, to its derivatives) via POST /api/v1/purge

purge
imgix_post_api_v1_sourcesWRITE

Create an imgix Source. The JSON:API body names the origin type (s3, gcs, azure, webfolder, webproxy, s3_compatible), the imgix subdomains it serves, and the credentials and options that origin type needs via POST /api/v1/sources

sources
imgix_post_api_v1_sources_by_source_id_assets_add_by_origin_pathWRITE

Index an object that already exists at the Source's origin into the Asset Manager. Answers 202: indexing is asynchronous, so read the asset back to see it appear via POST /api/v1/sources/{source_id}/assets/add/{origin_path}

asset_manager_edit
imgix_post_api_v1_sources_by_source_id_assets_refresh_by_origin_pathWRITE

Re-read an asset from the Source's origin and update its Asset Manager record, for when the bytes at the origin changed underneath imgix via POST /api/v1/sources/{source_id}/assets/refresh/{origin_path}

asset_manager_edit
imgix_post_api_v1_sources_by_source_id_upload_sessions_by_origin_pathWRITE

Open an upload session for an origin path and receive the session's id and upload target. This is the non-binary route to putting bytes in a Source: the caller transfers the file to the returned target directly, then closes the session via POST /api/v1/sources/{source_id}/upload-sessions/{origin_path}

asset_manager_edit
imgix_post_api_v1_sources_by_source_id_upload_sessions_by_session_idWRITE

Close an open upload session by its id, committing the uploaded object to the Source via POST /api/v1/sources/{source_id}/upload-sessions/{session_id}

asset_manager_edit
imgix_post_api_v1_unpublishWRITE

Withdraw assets from being served, so imgix stops answering requests for them via POST /api/v1/unpublish

asset_manager_edit

Put imgix behind one governed endpoint.

Same permissions, same audit trail, whatever else you connect next.