Fabric can now accept Iceberg writes—but credential vending does not remove commit conflicts

Microsoft Fabric’s OneLake table API now exposes Apache Iceberg REST Catalog operations for reads, native-table writes and credential vending. Microsoft’s accessible Learn documentation makes the operating boundary unusually clear: the client writes data, manifest and metadata files to OneLake, then separately commits the metadata update through the catalog endpoint. (Microsoft Learn)

Authorization is not commit validity

An Iceberg client can authenticate to storage directly or request temporary credentials from OneLake. Credential vending limits where a credential applies through a storage-location prefix, and clients must select the most specific matching prefix. Microsoft also warns that OneLake returns HTTPS prefixes while Iceberg metadata uses ABFS locations, so clients must reconcile those representations correctly. PyIceberg, Snowflake and DuckDB examples are available, but the client—not OneLake—still has to apply the credential to the right location. (Microsoft Learn)

That temporary authorization does not make a proposed commit current. Native Iceberg writes finish with a separate CommitTableRequest containing requirements and updates. Microsoft says those requirements provide optimistic-concurrency checks so conflicting updates fail rather than overwrite a newer table state. For an analytics agent or automated workflow, the safe sequence is therefore: load current state, write files, attempt the commit, and on conflict refresh state before deciding whether to retry or stop for review.

Know which tables are writable

The endpoint’s write path applies to native Iceberg tables. Virtual Iceberg metadata generated for Delta Lake tables is for read compatibility and does not accept Iceberg catalog commits; Delta-compatible writers must update the source table instead. Table shortcuts also cannot receive Iceberg metadata commits. Those distinctions should be explicit in an agent’s tool schema so a model cannot infer writability from the fact that a table can be listed or read. (Microsoft Learn)

The same caution applies to deletion. Microsoft documents that the drop-table operation removes the catalog entry and deletes the OneLake directory, including data and metadata. That is a destructive operation, not metadata cleanup, and should remain outside autonomous agent permissions.

A practical production receipt should record the table identifier, principal, starting snapshot, resulting snapshot and retry count. That lets operators distinguish expired or misapplied credentials from a concurrency conflict. OneLake’s endpoint improves interoperability, but it does not erase transaction boundaries: temporary credentials answer who may access storage; commit requirements answer whether this version may replace the current table state.