For those of you who've been keeping up with recent posts concerning confusion over the value of IDs returned by the API, the most recent commit to galaxy-central (5994:435e3f628e7d) addresses this issue. Here's the commit message: Do away with the encoding of 'file.<id>' and 'folder.<id>' in the API. All IDs in the API, with the exception of library folders, are now just the object's real encoded id. Library folders have an 'F' prepended to the id AFTER encoding. All real IDs (including the ldda ID of library datasets) can be seen in an item's element view. Workflows started from the API using the 'ld=' src should now use the new IDs as opposed to the old 'file.<id>' IDs. So: % ./display.py key http://foo/api/libraries/ebfb8f50c6abde6d/contents Collection Members ------------------ #1: /api/libraries/ebfb8f50c6abde6d/contents/Fa799d38679e985db name: / type: folder id: Fa799d38679e985db #2: /api/libraries/ebfb8f50c6abde6d/contents/4b187121143038ff name: /1.bed type: file id: 4b187121143038ff % ./display.py key http://foo/api/libraries/ebfb8f50c6abde6d/contents/Fa799d38679e985db Member Information ------------------ genome_build: hg18 item_count: 3 description: name: api3 id: a799d38679e985db % ./display.py key http://foo/api/libraries/ebfb8f50c6abde6d/contents/4b187121143038ff Member Information ------------------ ... id: 4b187121143038ff ldda_id: 4b187121143038ff model_class: LibraryDataset In this example the LibraryDatasetDatasetAssociation id and LibraryDataset id happen to be the same, this won't usually be the case on an established server. The API's run workflow method accepts LibraryDatasetDatasetAssociation, LibraryDataset, and HistoryDatasetAssocation ids. With this latest changeset, all of these can be obtained from the API. --nate