oci-api
A Rust client library for Oracle Cloud Infrastructure (OCI) APIs.
Currently supports:
- Email Delivery Service - Send emails via OCI Email Delivery
- Object Storage Service - Manage buckets and objects
- Vault Secrets Service - Read current, staged, and versioned secret bundles
- Keys Service - Read keys and trigger rotation
Features
- 🔐 OCI HTTP request signing (compliant with OCI specifications)
- 🔄 Dual auth modes: API key and Instance Principal
- 📧 Email Delivery API support
- 🗝️ Vault Secrets and Keys support
- 🔄 Async/await support (Tokio)
- 🛡️ Type-safe API with comprehensive error handling
- ⚙️ Flexible configuration (environment variables, config files, or programmatic)
Installation
Add this to your Cargo.toml:
[]
= "0.8.0"
= { = "1", = ["full"] }
Import commonly used types:
use Oci;
use ;
use KeysClient;
use ObjectStorage;
use VaultSecretsClient;
Configuration
oci-api supports two authentication modes via the OCI_AUTH_MODE environment variable:
| Mode | Value | Typical runtime |
|---|---|---|
| API key | api_key |
local development, CI, explicit credential injection |
| Instance Principal | instance_principal |
OCI-hosted runtime with instance identity |
When OCI_AUTH_MODE is unset, oci-api uses this precedence:
- Short OCI metadata probe (
/opc/v2/instance/regionInfo) - If OCI metadata is reachable, default to
instance_principal - Otherwise, fall back to
api_key
This keeps OCI-hosted runtimes on the workload-identity path by default while preserving API key usage for local and non-OCI environments.
Option A: Instance Principal
Use Instance Principal when the workload runs on OCI and should use the instance's workload identity. You can set it explicitly, or leave OCI_AUTH_MODE unset on OCI and let oci-api autodetect it.
OCI_AUTH_MODE=instance_principal
# optional: override metadata endpoint for local mock tests
OCI_METADATA_BASE_URL=http://169.254.169.254/opc/v2
use Oci;
let oci = from_env?;
assert_eq!;
Instance Principal notes:
- No auth credential environment variables are required on OCI-hosted runtimes.
OCI_REGIONandOCI_TENANCY_IDare auto-discovered when OCI metadata and the instance leaf certificate are available.- If
OCI_AUTH_MODEis unset, OCI metadata reachability makesinstance_principalthe default path. - Auth tokens, session keys, and service endpoints are resolved lazily and refreshed automatically.
- Resource-target variables such as secret OCIDs, bucket names, namespaces, or KMS endpoints remain separate from authentication configuration.
- The runtime must belong to a dynamic group with policies for each target OCI service.
- If the runtime is outside OCI, use
api_keymode instead.
Example Instance Principal policies
The exact policy set depends on the services you call. For the currently implemented services, read-oriented access typically looks like this:
Allow dynamic-group <dynamic-group-name> to read keys in compartment <compartment-name>
Allow dynamic-group <dynamic-group-name> to read secret-family in compartment <compartment-name>
Allow dynamic-group <dynamic-group-name> to read buckets in compartment <compartment-name>
Allow dynamic-group <dynamic-group-name> to read objects in compartment <compartment-name>
Allow dynamic-group <dynamic-group-name> to read email-family in compartment <compartment-name>
Notes:
- Keys and secrets are compartment-scoped.
- Object Storage object reads require
read objectsin addition toread buckets. - Email Delivery control-plane reads can be compartment-scoped.
Option B: API Key
Use API key mode for local development, CI, or any runtime outside OCI.
Option B-1: Environment Variables (Recommended)
OCI credentials used for generating(signing) Authorization headers and requests can be loaded from environment variables or from OCI_CONFIG.
Using OCI_CONFIG (supports both file path and INI content directly)
OCI_CONFIG can provide the following information:
user→user_idtenancy→tenancy_idregionfingerprintkey_file: path to private key file
# use dotenvy or similar to load environment variables from `.env` in development
# point to a config file path
OCI_CONFIG=/path/to/.oci/config
# or provide content(INI) directly
OCI_CONFIG="[DEFAULT]
user=ocid1.user.oc1..aaaaaa...
tenancy=ocid1.tenancy.oc1..aaaaaa...
region=ap-chuncheon-1
fingerprint=aa:bb:cc:dd:ee:ff:11:22:33:44:55:66:77:88:99:00
key_file=~/.oci/private-key.pem"
Using OCI_PRIVATE_KEY (supports both file path and PEM content directly):
# it overrides the private key specified in OCI_CONFIG if both are set
# Provide private key file path
OCI_PRIVATE_KEY=/path/to/private-key.pem
# or provide PEM content directly:
OCI_PRIVATE_KEY="-----BEGIN PRIVATE KEY-----
MIIEvwIBADANBgk...
-----END PRIVATE KEY-----"
Individual environment variables override OCI_CONFIG example:
# if you use individual vars, you don't need to set OCI_CONFIG
# but you can still use it as a base
OCI_CONFIG=/path/to/.oci/config
# Override specific values (higher priority than OCI_CONFIG)
OCI_USER_ID=ocid1.user.oc1..different... # Overrides 'user' from config
OCI_TENANCY_ID=ocid1.tenancy.oc1..different... # Overrides 'tenancy' from config
OCI_REGION=ap-seoul-1 # Overrides 'region' from config
OCI_FINGERPRINT=11:22:33:44:55:66:77:88:99:00:aa:bb:cc:dd:ee:ff # Overrides 'fingerprint'
OCI_PRIVATE_KEY=/different/path/to/key.pem # Overrides 'key_file' from config
OCI_COMPARTMENT_ID=ocid1.compartment.oc1..aaaaaa... # Optional, defaults to tenancy_id, but needed for APIs if you use specific compartment
Load configuration:
use Oci;
let oci = from_env?;
Priority Summary:
| Field | Priority 1 | Priority 2 |
|---|---|---|
| User ID | OCI_USER_ID |
user from OCI_CONFIG |
| Tenancy ID | OCI_TENANCY_ID |
tenancy from OCI_CONFIG |
| Region | OCI_REGION |
region from OCI_CONFIG |
| Fingerprint | OCI_FINGERPRINT |
fingerprint from OCI_CONFIG |
| Private Key | OCI_PRIVATE_KEY (file path or content) |
key_file from OCI_CONFIG |
| Compartment ID | OCI_COMPARTMENT_ID |
Defaults to tenancy_id |
* OCI_USER_ID, OCI_TENANCY_ID, OCI_REGION, OCI_FINGERPRINT, and OCI_PRIVATE_KEY are required if OCI_CONFIG is not set.
* OCI_PRIVATE_KEY is recommended even if OCI_CONFIG is used, if you do not want to change the config file content between environments.
Option B-2: Programmatic Configuration
use Oci;
// build from scratch using individual fields
let oci = builder
.user_id
.tenancy_id
.region
.fingerprint
.private_key?
.compartment_id
.build?;
// or load from config file and override specific fields
let oci = builder
.config? // Load from file
.private_key? // Override key_file from config
.compartment_id // Set compartment
.build?;
Email Delivery API
use Oci;
use ;
async
Body Text & HTML
you can send body as text or HTML or both, but at least one is required. if both are provided(recommended), email clients will choose HTML if available, otherwise plain text.
use Oci;
use ;
let email = builder
.sender
.recipients
.subject
.body_html
.body_text
.build?;
let response = email_delivery.send.await?;
Email Address
EmailAddress is used for specifying sender, recipients, reply-to, etc. it can be created with just an email(new) or with a display name(with_name).
let just_email = new;
let with_name = with_name;
Recipients
Recipients needs at least one to or cc or bcc recipient.
You can use builder pattern or multiple Recipients constructors(to(=new), cc, bcc) to create recipients,
and you can also add more recipients using add_to, add_cc, add_bcc methods.
each to, cc, bcc recipients will be unique by EmailAddress.email when constructed or added.
// Option 1: Using builder pattern (flexible for multiple fields)
let email = builder
.sender
.subject
.body_text
.recipients
.build?;
// Option 2: Using specific constructor and add with `add_*` methods (chainable)
let email = builder
.sender
.subject
.body_text
.recipients
.build?;
let response = email_client.send.await?;
You can also use headers(headerFields), reply_to(replyTo), and message_id(messageId) fields in Email struct. you can reference here
Testing with EmailSender trait
EmailDelivery implements the EmailSender trait, which allows you to inject mock implementations for testing:
use ;
use ;
use ;
// Create a mock implementation for testing
// Use trait object for dependency injection
async
This pattern lets you:
- Production: Use
Arc<dyn EmailSender>withEmailDelivery(real OCI API) - Test: Use
Arc<dyn EmailSender>with a mock (no network calls, verify sent emails)
For OCI Email Delivery documentation, see:
- OCI Email Delivery Overview
- OCI Email Delivery API Reference
- OCI Email Delivery Submission API Reference
Object Storage API
use Oci;
use ObjectStorage;
async
you can also work with retention rules for a bucket
use ;
async
Object Integrity
It automatically maps available checksum headers into md5(Content-MD5)
and checksum(opc-content-sha256|opc-content-sha384|opc-content-crc32c) fields.
You can verify the integrity of the downloaded object using the verify_checksums() method.
use ChecksumAlgorithm;
let object = bucket.get_object.await?;
// Verify integrity against all available checksums
// Returns Ok(()) if all present checksums match, or an Error if any mismatch
object.verify_checksums?;
// Access specific checksums
println!;
if let Some = &object.checksum
For OCI Object Storage documentation, see:
Vault Secrets API
use Oci;
async
Phase 1 scope intentionally focuses on:
- current secret bundle lookup
- staged secret bundle lookup
- versioned secret bundle lookup
Keys API
use Oci;
async
Phase 1 scope intentionally focuses on:
- key lookup
- rotate action
Error Handling
The library provides comprehensive error types:
use ;
match email_client.send.await
Error types:
ConfigError- Configuration loading/validation errorsEnvError- Environment variable errorsKeyError- Private key loading errorsAuthError- Authentication/signing errorsApiError- OCI API errors (with HTTP status and response body)NetworkError- Network/HTTP client errorsIniError- Config file parsing errorsOther- Other errors
License
MIT
Contributing
Contributions are welcome! Please feel free to submit a Pull Request.
Support
For issues and feature requests, please use GitHub Issues. You can request any OCI APIs, and I will try to implement them as soon as possible.