# APIs and Common Features

APIs are the heart of the Cloud reactor. They are used to integrate with the logic of Cloud providers, and are ubiquitous in the software development kits of all computing languages. Beyond that, Cloud providers seem to have common characteristics that enable the existence of a solution like [Flashback](https://platform.flashback.tech):

* [APIs](#apis)
* [Common Features](#common-features)

***

## APIs

At the heart of cloud storage lies the **object storage API**, which provides CRUD-like operations for managing buckets and objects (files). Most APIs expose endpoints for:

* Creating and managing *buckets* (logical containers for data)
* Uploading, downloading, and deleting *objects*
* Managing object *metadata* and *permissions*

#### **Popular API Documentation Links**:

* [AWS S3 API Reference](https://docs.aws.amazon.com/AmazonS3/latest/API/Welcome.html)
* [Google Cloud Storage JSON API](https://cloud.google.com/storage/docs/apis)
* [Azure Blob Storage REST API](https://learn.microsoft.com/en-us/rest/api/storageservices/blob-service-rest-api)
* [Storj Uplink](https://storj.dev/dcs/api/uplink-cli) and S3-Compatible Gateway Docs
* [Lotus API](https://lotus.filecoin.io/reference/basics/api-access/) and other Filecoin Client Libraries

Most centralized providers also support **SDKs** in multiple programming languages, while decentralized options often offer command-line tools and API gateways for compatibility.

### **Common Ways to Access Cloud Storage APIs**

Whether using centralized or decentralized cloud storage, secure access to APIs is essential. Here are the most common methods used by developers and applications to authenticate and interact with object storage systems:

#### **1. API Key and Secret (Access Keys)**

This is the **default and most common method** for programmatic access in centralized systems:

* Consists of a **public access key ID** and a **secret access key**.
* Used to **sign requests**, often via HMAC or similar algorithms (e.g., AWS Signature v4).
* These keys should be **kept secret**, rotated regularly, and scoped to the least privilege necessary.

**Used by:**\
✅ AWS S3, GCP, Azure, Storj (Uplink), MinIO, and other S3-compatible APIs.

{% hint style="info" %}
**Tip:** Avoid hardcoding credentials. Use environment variables or cloud-native credential providers (like AWS IAM roles or Google Service Accounts).
{% endhint %}

#### **2. Delegated Access to External Users**

This enables controlled and temporary access to objects or buckets by third parties, **without exposing your main credentials**.

* **Pre-signed URLs / Signed URLs**\
  Allow secure, time-limited access to specific objects. Can be generated with custom permissions (read, write, delete).

  ✅ Supported by AWS S3, Google Cloud Storage, Azure Blob (via SAS tokens), and Storj.
* **Access Control Lists (ACLs) & Bucket Policies**\
  Define read/write permissions at the bucket or object level, including granting access to specific users, roles, or anonymous users.
* **Federated Identity / Temporary Credentials**\
  Integrates with identity providers (e.g., Cognito, Google Identity, Active Directory) to generate scoped temporary tokens (STS) for users or applications.

  ✅ Ideal for mobile apps, short-lived tasks, or public-facing apps.

#### **3. OAuth 2.0 and Service Accounts**

Some providers, especially **Google Cloud and Azure**, support OAuth 2.0:

* Used to **authorize** applications or users to access storage on behalf of someone else.
* Service accounts (for back-end applications) or user accounts (for delegated access) can request tokens from OAuth providers.

**Used by:**\
✅ Google Cloud Storage, Azure Blob, and some third-party tools integrating with cloud storage.

#### **4. Web3 / Decentralized Identity Access (DePIN solutions)**

Decentralized storage systems use blockchain-native authentication methods:

* **Public-Private Key Signing**\
  Wallet-based authentication where users sign requests using their **crypto wallets** (e.g., Ethereum, Filecoin, Arweave wallets).
* **Token-based access**\
  Filecoin and others use **network tokens** to pay for storage and authorize uploads/downloads.

  ✅ Storj uses a custom identity system based on cryptographic keys and satellite nodes.\
  ✅ Filecoin requires interaction with smart contracts and storage miners.

#### **5. SDKs and CLI Tools** 

Most platforms offer **language-specific SDKs** and **command-line tools** that abstract away the low-level signing and access mechanics:

* Examples: `aws-cli`, `gsutil`, `azcopy`, `uplink` (Storj), and IPFS/Filecoin clients.
* Useful for scripting, debugging, and batch uploads/downloads.

These tools often handle credentials securely via local configuration files or integration with cloud-native identity systems.

### **Security Best Practices**

* **Use roles and policies** instead of assigning full-access keys to all services.
* **Enable MFA and logging** for access management.
* **Scope permissions** tightly to resources, actions, and durations.

***

## Common Features

Despite different providers and underlying architectures, most object storage platforms offer a common set of features:

| **Feature**                  | **Description**                                                                 |
| ---------------------------- | ------------------------------------------------------------------------------- |
| **Object Versioning**        | Automatically stores multiple versions of the same object.                      |
| **Encryption**               | Data-at-rest and in-transit encryption, often with customer-managed keys.       |
| **Access Control**           | IAM roles, bucket policies, signed URLs for controlled access.                  |
| **Multi-region Replication** | Redundancy across regions for availability and compliance.                      |
| **Lifecycle Management**     | Auto-transitioning objects between tiers (hot/warm/cold) or scheduled deletion. |
| **Storage Classes**          | Different pricing tiers for hot (frequent), cold (infrequent), and archive.     |
| **Event Notification**       | Trigger events (e.g., Lambda, Pub/Sub) on object creation or deletion.          |
| **API Compatibility**        | S3 API has become a de facto standard; many services offer S3-compatible APIs.  |

Understanding these shared features helps in evaluating and switching between providers, especially for multi-cloud strategies or hybrid architectures.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.flashback.tech/getting-started/learn-more/apis-and-common-features.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.