IaGenify SDK 0.2: resource objects show what applications need.

An SDK is the boundary between a service and the applications that use it. That boundary is easier to work with when its objects describe the operations developers need, instead of mirroring internal storage layouts or transport details. IaGenify SDK 0.2 makes that distinction clearer for files and connected storage.

Files are resources, not server paths

An application needs to identify a file, read it, update it or remove it. It does not need to know which directory on a service machine currently holds the bytes. The SDK's file object therefore centers on its source identifier and the file operations that use it, rather than a host-specific path.

const file = await api.files.get(sourceId);
console.log(file.sourceId);
file.content = "Revised note";
await file.update();

Stable identifiers make application code portable. The same reference can be used from a local tool, a web interface or an automation without teaching each caller about the service's filesystem. It also means the service can change how it stores files without forcing every application to change with it.

Connected storage should expose useful actions

A connected storage resource is most useful when it gives the application a safe way to operate on the connection. The public object exposes its identity and supported operations; credentials and implementation-specific connection data are not a feature an application should need to inspect just to list or use its storage.

const storage = await api.storage.get({ id: storageId });
console.log(storage.id);
const files = await storage.run({ action: "list", path: "/reports" });

This keeps responsibilities separate: the application chooses an operation, and the service uses the stored connection configuration to perform it. Callers do not need to copy connection details into their own state or build a second credential-handling layer around the SDK.

A smaller public surface is easier to maintain

When an SDK returns implementation details, application code can start depending on them even if they were never intended as a stable contract. Removing those accidental dependencies later becomes a breaking change. A focused resource shape makes the supported contract easier to document, version and use across runtimes.

This is not about hiding useful behavior. It is about exposing behavior at the right level: identifiers for addressing resources, methods for supported operations, and results that describe what the caller can act on. The SDK can then evolve its internals without making every integration an internal service client.

The principle behind 0.2

IaGenify SDK 0.2 is a small release with a useful design principle: public objects should carry the information an application needs to work, and no more implementation detail than the contract requires. Files and storage become easier to reason about because their interfaces follow the resource, not the service machine behind it.

A dependable SDK gives developers stable handles and clear actions, while the service keeps ownership of its implementation.