revenium-python-sdk 0.5.0__tar.gz → 0.7.0__tar.gz

{revenium_python_sdk-0.5.0 → revenium_python_sdk-0.7.0}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: revenium-python-sdk
-Version: 0.5.0
+Version: 0.7.0
 Summary: The official Revenium Python SDK — unified AI metering middleware for OpenAI, Anthropic, Google, Ollama, LiteLLM, Perplexity, and fal.ai.
 Author-email: Revenium <support@revenium.io>
 License: MIT
@@ -214,6 +214,52 @@ print(response.choices[0].message.content)
 
 ---
 
+## Metering Error Visibility
+
+Metering runs in background threads and never raises into your code path — a
+metering failure will never break your AI calls. To make failures observable
+anyway, the SDK provides two mechanisms:
+
+**Subscribe to failures** with a callback:
+
+```python
+import revenium_middleware
+
+@revenium_middleware.on_metering_error
+def alert_on_metering_failure(event):
+    # event.error      -- the exception (e.g. an HTTP 401/500 from Revenium)
+    # event.operation  -- "completion", "image", "tool", ... (may be None)
+    # event.timestamp  -- UTC datetime of the failure
+    my_monitoring.notify(f"Revenium metering failed: {event.error}")
+```
+
+Callbacks run on the background metering thread; exceptions they raise are
+suppressed and logged, so they can never disrupt your application.
+
+Authentication headers (`x-api-key`, `authorization`) on any HTTP
+request/response attached to the exception are redacted before the error is
+exposed to callbacks or `last_error`.
+
+**Poll the status counters:**
+
+```python
+status = revenium_middleware.get_metering_status()
+print(status.success_count)   # events delivered successfully
+print(status.error_count)     # delivery failures
+print(status.last_error)      # most recent exception, or None
+print(status.last_error_at)   # UTC datetime of the most recent failure
+```
+
+`reset_metering_status()` zeroes the counters and clears registered
+callbacks; `remove_metering_error_callback(cb)` unsubscribes a single one.
+
+Failures are also logged at **ERROR** level on the `revenium_middleware`
+logger, including HTTP 4xx/5xx responses, a missing
+`REVENIUM_METERING_API_KEY`, and a provider middleware that fails to import
+when the provider's SDK is installed.
+
+---
+
 ## Agentic Outcomes (Outcome-Based Metering)
 
 Emit per-agent terminal outcomes (`CONVERTED`, `DEFLECTED`, `ESCALATED`) alongside completion and tool-event records, so dashboards show business value next to AI cost.
@@ -265,7 +311,10 @@ history = get_outcome_history("sales-lead-8842")
 # List[JobOutcomeAmendment], ordered by amendment_sequence (1 = the initial report)
 ```
 
-`amend_outcome()` takes a mandatory non-blank `reason` plus the same optional fields as `report_outcome()` (`execution_status`, `outcome_type`, `outcome_value`, `outcome_currency`, `metadata`, `reported_by`), and returns the updated job as a dict.
+`amend_outcome()` takes a mandatory non-blank `reason` plus the same optional fields as `report_outcome()` (`execution_status`, `outcome_type`, `outcome_value`, `outcome_currency`, `metadata`, `reported_by`, `outcome_reason`), and returns the updated job as a dict.
+
+- **`reason` vs `outcome_reason`:** `reason` is the amendment's own audit justification (why the record changed); `outcome_reason` is the business explanation of why the job failed or was cancelled. Use `outcome_reason` for failure explanations rather than burying them in `metadata` — it is a first-class field on the outcome and is returned on every `get_outcome_history()` row.
+- **Clearing `outcome_reason`:** omit the argument to leave the stored value untouched; pass an empty string (`outcome_reason=""`) to clear it.
 
 ### Outcome Exceptions
 
@@ -733,6 +782,7 @@ litellm_settings:
 ```
 
 When using the LiteLLM proxy, pass metadata via HTTP headers (`x-revenium-*`).
+Reasoning effort travels as `x-revenium-effort` on the proxied request.
 
 #### LiteLLM Decorators
 
@@ -1025,6 +1075,7 @@ Add business context to any API call by passing a `usage_metadata` dictionary. A
 | `productName` | Your product or feature name | Attribute AI costs to specific features (e.g., `"customer-chatbot"`, `"email-assistant"`). Auto-creates if not found |
 | `agent` | AI agent or bot identifier | Distinguish between multiple AI agents or automation workflows |
 | `response_quality_score` | Custom quality rating (0.0-1.0) | Track user satisfaction or automated quality metrics for model performance analysis |
+| `effort` | Reasoning effort level requested of the model (free-form string, max 16 chars, `^[A-Za-z0-9_-]+$`) | Report what share of AI spend is high-effort reasoning, and compare cost per effort level |
 
 **Example:**
 
@@ -1047,11 +1098,27 @@ response = client.chat.completions.create(
         "subscription_id": "pro-plan-Q1",
         "productName": "customer-support-chatbot",
         "agent": "support-agent",
-        "response_quality_score": 0.92
+        "response_quality_score": 0.92,
+        "effort": "high"
     }
 )
 ```
 
+**Reasoning effort:** `effort` records how hard the model was asked to think, so
+high-effort reasoning spend can be separated from the rest. It is a free-form
+string, not an enum -- vendor vocabularies differ and drift, so `low`, `medium`,
+`high`, `xhigh` and `ultra` are all real values, and a level this SDK release has
+never heard of is passed through untouched rather than rejected or rewritten. The
+Revenium backend owns validation (at most 16 characters, matching
+`^[A-Za-z0-9_-]+$`); a value it rejects fails the metering call visibly instead
+of being silently dropped, so it surfaces in the log and in
+`get_metering_status()`. It is distinct from the reported reasoning token count,
+which measures the tokens actually spent rather than the level requested.
+
+Set it per call in `usage_metadata` on any provider integration. In LiteLLM proxy
+mode, where per-call attribution travels as request headers rather than
+`usage_metadata`, send `x-revenium-effort` instead.
+
 **Deprecation notice:** The legacy field aliases `organizationId`, `organization_id`, `productId`, and `product_id` are accepted by this SDK only as an input-layer convenience and emit a `DeprecationWarning`. The Revenium backend no longer accepts them — they are translated to `organizationName` / `productName` before the wire call. Migrate to `organization_name` / `organizationName` and `product_name` / `productName` now; the input-layer aliases will be removed in the next major release.
 
 **API Reference:** [Complete metadata field documentation](https://revenium.readme.io/reference/meter_ai_completion)
@@ -1075,6 +1142,12 @@ Enhanced observability fields for tracking AI operations across environments, re
 | `transaction_name` | `REVENIUM_TRANSACTION_NAME` | Human-friendly operation name | Label operations (e.g., `"Generate Response"`, `"Analyze Sentiment"`) |
 | `retry_number` | `REVENIUM_RETRY_NUMBER` | Retry attempt number (0 = first attempt) | Track retry attempts for failed operations |
 | `ticket_id` | `REVENIUM_TICKET_ID` | External ticket or issue ID (e.g., Jira, Linear) (max 256 chars) | Attribute AI costs to individual tickets or issues |
+| `skill_name` | `REVENIUM_SKILL_NAME` | Name of the agent skill that produced the call (max 256 chars) | Attribute AI costs to the skill that generated them |
+| `skill_source` | `REVENIUM_SKILL_SOURCE` | Where the skill was loaded from — accepted values: `bundled`, `projectSettings`, `userSettings`, `plugin` (case-sensitive) | Classify skill origin in the shared skill catalog |
+| `skill_kind` | `REVENIUM_SKILL_KIND` | Kind of skill invoked — accepted value: `workflow` (omit otherwise) | Distinguish workflow skills in reporting |
+| `skill_plugin_name` | `REVENIUM_SKILL_PLUGIN_NAME` | Plugin providing the skill, when `skill_source` is `plugin` (max 256 chars) | Attribute costs to a specific plugin |
+| `skill_marketplace_name` | `REVENIUM_SKILL_MARKETPLACE_NAME` | Marketplace the skill or plugin was installed from (max 256 chars) | Track marketplace-sourced skill usage |
+| `skill_invocation_trigger` | `REVENIUM_SKILL_INVOCATION_TRIGGER` | What triggered the skill (max 32 chars; common values: `user-slash`, `claude-proactive`, `nested-skill`) | Separate user-invoked from proactive skill usage |
 
 **Note:** `operation_type` (e.g., `CHAT`, `EMBED`, `TOOL_CALL`) and `operation_subtype` (e.g., `function_call`, `streaming`) are automatically detected by the middleware and cannot be overridden.
 

{revenium_python_sdk-0.5.0 → revenium_python_sdk-0.7.0}/README.md

@@ -117,6 +117,52 @@ print(response.choices[0].message.content)
 
 ---
 
+## Metering Error Visibility
+
+Metering runs in background threads and never raises into your code path — a
+metering failure will never break your AI calls. To make failures observable
+anyway, the SDK provides two mechanisms:
+
+**Subscribe to failures** with a callback:
+
+```python
+import revenium_middleware
+
+@revenium_middleware.on_metering_error
+def alert_on_metering_failure(event):
+    # event.error      -- the exception (e.g. an HTTP 401/500 from Revenium)
+    # event.operation  -- "completion", "image", "tool", ... (may be None)
+    # event.timestamp  -- UTC datetime of the failure
+    my_monitoring.notify(f"Revenium metering failed: {event.error}")
+```
+
+Callbacks run on the background metering thread; exceptions they raise are
+suppressed and logged, so they can never disrupt your application.
+
+Authentication headers (`x-api-key`, `authorization`) on any HTTP
+request/response attached to the exception are redacted before the error is
+exposed to callbacks or `last_error`.
+
+**Poll the status counters:**
+
+```python
+status = revenium_middleware.get_metering_status()
+print(status.success_count)   # events delivered successfully
+print(status.error_count)     # delivery failures
+print(status.last_error)      # most recent exception, or None
+print(status.last_error_at)   # UTC datetime of the most recent failure
+```
+
+`reset_metering_status()` zeroes the counters and clears registered
+callbacks; `remove_metering_error_callback(cb)` unsubscribes a single one.
+
+Failures are also logged at **ERROR** level on the `revenium_middleware`
+logger, including HTTP 4xx/5xx responses, a missing
+`REVENIUM_METERING_API_KEY`, and a provider middleware that fails to import
+when the provider's SDK is installed.
+
+---
+
 ## Agentic Outcomes (Outcome-Based Metering)
 
 Emit per-agent terminal outcomes (`CONVERTED`, `DEFLECTED`, `ESCALATED`) alongside completion and tool-event records, so dashboards show business value next to AI cost.
@@ -168,7 +214,10 @@ history = get_outcome_history("sales-lead-8842")
 # List[JobOutcomeAmendment], ordered by amendment_sequence (1 = the initial report)
 ```
 
-`amend_outcome()` takes a mandatory non-blank `reason` plus the same optional fields as `report_outcome()` (`execution_status`, `outcome_type`, `outcome_value`, `outcome_currency`, `metadata`, `reported_by`), and returns the updated job as a dict.
+`amend_outcome()` takes a mandatory non-blank `reason` plus the same optional fields as `report_outcome()` (`execution_status`, `outcome_type`, `outcome_value`, `outcome_currency`, `metadata`, `reported_by`, `outcome_reason`), and returns the updated job as a dict.
+
+- **`reason` vs `outcome_reason`:** `reason` is the amendment's own audit justification (why the record changed); `outcome_reason` is the business explanation of why the job failed or was cancelled. Use `outcome_reason` for failure explanations rather than burying them in `metadata` — it is a first-class field on the outcome and is returned on every `get_outcome_history()` row.
+- **Clearing `outcome_reason`:** omit the argument to leave the stored value untouched; pass an empty string (`outcome_reason=""`) to clear it.
 
 ### Outcome Exceptions
 
@@ -636,6 +685,7 @@ litellm_settings:
 ```
 
 When using the LiteLLM proxy, pass metadata via HTTP headers (`x-revenium-*`).
+Reasoning effort travels as `x-revenium-effort` on the proxied request.
 
 #### LiteLLM Decorators
 
@@ -928,6 +978,7 @@ Add business context to any API call by passing a `usage_metadata` dictionary. A
 | `productName` | Your product or feature name | Attribute AI costs to specific features (e.g., `"customer-chatbot"`, `"email-assistant"`). Auto-creates if not found |
 | `agent` | AI agent or bot identifier | Distinguish between multiple AI agents or automation workflows |
 | `response_quality_score` | Custom quality rating (0.0-1.0) | Track user satisfaction or automated quality metrics for model performance analysis |
+| `effort` | Reasoning effort level requested of the model (free-form string, max 16 chars, `^[A-Za-z0-9_-]+$`) | Report what share of AI spend is high-effort reasoning, and compare cost per effort level |
 
 **Example:**
 
@@ -950,11 +1001,27 @@ response = client.chat.completions.create(
         "subscription_id": "pro-plan-Q1",
         "productName": "customer-support-chatbot",
         "agent": "support-agent",
-        "response_quality_score": 0.92
+        "response_quality_score": 0.92,
+        "effort": "high"
     }
 )
 ```
 
+**Reasoning effort:** `effort` records how hard the model was asked to think, so
+high-effort reasoning spend can be separated from the rest. It is a free-form
+string, not an enum -- vendor vocabularies differ and drift, so `low`, `medium`,
+`high`, `xhigh` and `ultra` are all real values, and a level this SDK release has
+never heard of is passed through untouched rather than rejected or rewritten. The
+Revenium backend owns validation (at most 16 characters, matching
+`^[A-Za-z0-9_-]+$`); a value it rejects fails the metering call visibly instead
+of being silently dropped, so it surfaces in the log and in
+`get_metering_status()`. It is distinct from the reported reasoning token count,
+which measures the tokens actually spent rather than the level requested.
+
+Set it per call in `usage_metadata` on any provider integration. In LiteLLM proxy
+mode, where per-call attribution travels as request headers rather than
+`usage_metadata`, send `x-revenium-effort` instead.
+
 **Deprecation notice:** The legacy field aliases `organizationId`, `organization_id`, `productId`, and `product_id` are accepted by this SDK only as an input-layer convenience and emit a `DeprecationWarning`. The Revenium backend no longer accepts them — they are translated to `organizationName` / `productName` before the wire call. Migrate to `organization_name` / `organizationName` and `product_name` / `productName` now; the input-layer aliases will be removed in the next major release.
 
 **API Reference:** [Complete metadata field documentation](https://revenium.readme.io/reference/meter_ai_completion)
@@ -978,6 +1045,12 @@ Enhanced observability fields for tracking AI operations across environments, re
 | `transaction_name` | `REVENIUM_TRANSACTION_NAME` | Human-friendly operation name | Label operations (e.g., `"Generate Response"`, `"Analyze Sentiment"`) |
 | `retry_number` | `REVENIUM_RETRY_NUMBER` | Retry attempt number (0 = first attempt) | Track retry attempts for failed operations |
 | `ticket_id` | `REVENIUM_TICKET_ID` | External ticket or issue ID (e.g., Jira, Linear) (max 256 chars) | Attribute AI costs to individual tickets or issues |
+| `skill_name` | `REVENIUM_SKILL_NAME` | Name of the agent skill that produced the call (max 256 chars) | Attribute AI costs to the skill that generated them |
+| `skill_source` | `REVENIUM_SKILL_SOURCE` | Where the skill was loaded from — accepted values: `bundled`, `projectSettings`, `userSettings`, `plugin` (case-sensitive) | Classify skill origin in the shared skill catalog |
+| `skill_kind` | `REVENIUM_SKILL_KIND` | Kind of skill invoked — accepted value: `workflow` (omit otherwise) | Distinguish workflow skills in reporting |
+| `skill_plugin_name` | `REVENIUM_SKILL_PLUGIN_NAME` | Plugin providing the skill, when `skill_source` is `plugin` (max 256 chars) | Attribute costs to a specific plugin |
+| `skill_marketplace_name` | `REVENIUM_SKILL_MARKETPLACE_NAME` | Marketplace the skill or plugin was installed from (max 256 chars) | Track marketplace-sourced skill usage |
+| `skill_invocation_trigger` | `REVENIUM_SKILL_INVOCATION_TRIGGER` | What triggered the skill (max 32 chars; common values: `user-slash`, `claude-proactive`, `nested-skill`) | Separate user-invoked from proactive skill usage |
 
 **Note:** `operation_type` (e.g., `CHAT`, `EMBED`, `TOOL_CALL`) and `operation_subtype` (e.g., `function_call`, `streaming`) are automatically detected by the middleware and cannot be overridden.
 

{revenium_python_sdk-0.5.0 → revenium_python_sdk-0.7.0}/pyproject.toml

@@ -4,7 +4,7 @@ build-backend = "setuptools.build_meta"
 
 [project]
 name = "revenium-python-sdk"
-version = "0.5.0"
+version = "0.7.0"
 description = "The official Revenium Python SDK — unified AI metering middleware for OpenAI, Anthropic, Google, Ollama, LiteLLM, Perplexity, and fal.ai."
 readme = "README.md"
 requires-python = ">=3.8"
@@ -124,6 +124,7 @@ dev = [
 ]
 
 [tool.pytest.ini_options]
+testpaths = ["tests"]
 markers = [
     "unit: Unit tests (fast, no external dependencies)",
     "e2e: end-to-end tests requiring live services",

{revenium_python_sdk-0.5.0 → revenium_python_sdk-0.7.0}/revenium_middleware/__init__.py

@@ -160,6 +160,16 @@ from ._core import (  # noqa: E402
     is_selective_metering_enabled,
 )
 
+# Metering error visibility (BACK-778): status counters + failure callbacks
+from ._core.metering_status import (  # noqa: E402
+    MeteringErrorEvent,
+    MeteringStatus,
+    get_metering_status,
+    on_metering_error,
+    remove_metering_error_callback,
+    reset_metering_status,
+)
+
 # Re-export tool metering utilities from the in-package metering module (BACK-2151)
 from ._metering import meter_tool, report_tool_call, configure  # noqa: E402
 
@@ -202,6 +212,13 @@ __all__ = [
     "set_idempotency_key",
     # Config exports
     "is_selective_metering_enabled",
+    # Metering error visibility exports (BACK-778)
+    "MeteringErrorEvent",
+    "MeteringStatus",
+    "get_metering_status",
+    "on_metering_error",
+    "remove_metering_error_callback",
+    "reset_metering_status",
     # Tool metering exports
     "meter_tool",
     "report_tool_call",

revenium_python_sdk-0.7.0/revenium_middleware/_core/cache_tokens.py

@@ -0,0 +1,109 @@
+"""Tolerant field access for provider usage objects (dict or attribute-style).
+
+Cache token fields differ by provider surface:
+
+- Anthropic-style: top-level ``cache_read_input_tokens`` / ``cache_creation_input_tokens``,
+  plus the nested per-TTL breakdown under ``cache_creation``.
+- OpenAI-style: nested ``prompt_tokens_details.cached_tokens``; no separate
+  cache-creation count.
+
+See BACK-2391 for the history of this bug class (hardcoded/zeroed cache-token
+fields recurring across multiple emitters) and BACK-1925 for the LiteLLM
+client's cache-token contract, which this module's defaults must not break.
+"""
+from numbers import Number
+from typing import Any, Dict, NamedTuple, Optional
+
+
+class CacheTokens(NamedTuple):
+    cache_read_tokens: int
+    cache_creation_tokens: int
+
+
+def _get(source: Any, name: str) -> Any:
+    """Read `name` from a dict or an attribute-style object; None if absent."""
+    if source is None:
+        return None
+    if isinstance(source, dict):
+        return source.get(name)
+    return getattr(source, name, None)
+
+
+def get_usage_field(usage: Any, name: str, default: int = 0) -> Any:
+    """Read a single usage field through the same tolerant accessor as
+    `extract_cache_tokens`, so cache fields and base token fields (prompt/
+    completion/total) are read consistently from the same dict-or-object
+    usage value. Missing or None fields return `default`.
+
+    Normalizing a usage object to a plain dict *before* reading it (e.g. to
+    simplify a `.get(...)` call) silently drops every field for
+    attribute-style usage objects that fall through that normalization --
+    exactly the inconsistency this function exists to prevent. Callers with
+    multiple fields to read from the same `usage` value should read all of
+    them through this function (or `extract_cache_tokens`) rather than
+    normalizing `usage` itself first.
+    """
+    value = _get(usage, name)
+    return default if value is None else value
+
+
+def extract_cache_tokens(usage: Any) -> CacheTokens:
+    """Extract (cache_read_tokens, cache_creation_tokens) from a usage object.
+
+    Tolerates dicts and attribute-style objects (SimpleNamespace, SDK response
+    models) and treats missing or None fields as 0. Checked in order:
+
+    1. OpenAI-style nested cache reads: ``usage.prompt_tokens_details.cached_tokens``
+    2. Anthropic-style top-level cache reads: ``usage.cache_read_input_tokens``
+    3. Anthropic-style top-level cache creation: ``usage.cache_creation_input_tokens``
+    """
+    prompt_details = _get(usage, "prompt_tokens_details")
+    cache_read_tokens = get_usage_field(prompt_details, "cached_tokens", 0)
+    if not cache_read_tokens:
+        cache_read_tokens = get_usage_field(usage, "cache_read_input_tokens", 0)
+    cache_creation_tokens = get_usage_field(usage, "cache_creation_input_tokens", 0)
+
+    return CacheTokens(cache_read_tokens=cache_read_tokens, cache_creation_tokens=cache_creation_tokens)
+
+
+def _optional_token_count(source: Any, name: str) -> Optional[int]:
+    """Read an integral token count, or None when it is absent or unusable.
+
+    Unlike `get_usage_field`, a missing field is reported as None rather than
+    coerced to 0, so callers can tell "the provider reported zero" apart from
+    "the provider reported nothing". Non-numeric values (including the
+    attributes that attribute-style test doubles auto-create on access) count
+    as nothing rather than being forwarded into a metering payload.
+    """
+    value = _get(source, name)
+    if isinstance(value, bool) or not isinstance(value, Number):
+        return None
+    return int(value)
+
+
+def extract_cache_creation_ttl_counts(usage: Any) -> Dict[str, int]:
+    """Extract the per-TTL cache-creation breakdown as metering parameters.
+
+    Anthropic reports the split under a nested ``usage.cache_creation`` object
+    (``ephemeral_5m_input_tokens`` / ``ephemeral_1h_input_tokens``). That
+    object is absent on older responses and whenever the extended cache-TTL
+    beta is not in play, so it is read defensively.
+
+    Returns metering parameter names mapped to the counts the provider
+    actually reported, ready to be merged into a metering payload. A bucket the
+    provider did not report is left out entirely instead of being sent as a
+    zero: the aggregate ``cache_creation_token_count`` stays authoritative and
+    the backend prices the flat fallback from it when no split is present,
+    whereas an explicit zero would assert a split that never happened. A
+    bucket the provider does report as 0 is forwarded as 0.
+    """
+    cache_creation = _get(usage, "cache_creation")
+
+    counts: Dict[str, int] = {}
+    ephemeral_5m = _optional_token_count(cache_creation, "ephemeral_5m_input_tokens")
+    if ephemeral_5m is not None:
+        counts["cache_creation5m_token_count"] = ephemeral_5m
+    ephemeral_1h = _optional_token_count(cache_creation, "ephemeral_1h_input_tokens")
+    if ephemeral_1h is not None:
+        counts["cache_creation1h_token_count"] = ephemeral_1h
+    return counts

{revenium_python_sdk-0.5.0 → revenium_python_sdk-0.7.0}/revenium_middleware/_core/config.py

@@ -63,6 +63,13 @@ class Config:
     ENV_REVENIUM_AGENTIC_JOB_NAME: str = "REVENIUM_AGENTIC_JOB_NAME"
     ENV_REVENIUM_AGENTIC_JOB_TYPE: str = "REVENIUM_AGENTIC_JOB_TYPE"
     ENV_REVENIUM_AGENTIC_JOB_VERSION: str = "REVENIUM_AGENTIC_JOB_VERSION"
+    # Skill attribution environment variables
+    ENV_REVENIUM_SKILL_INVOCATION_TRIGGER: str = "REVENIUM_SKILL_INVOCATION_TRIGGER"
+    ENV_REVENIUM_SKILL_KIND: str = "REVENIUM_SKILL_KIND"
+    ENV_REVENIUM_SKILL_MARKETPLACE_NAME: str = "REVENIUM_SKILL_MARKETPLACE_NAME"
+    ENV_REVENIUM_SKILL_NAME: str = "REVENIUM_SKILL_NAME"
+    ENV_REVENIUM_SKILL_PLUGIN_NAME: str = "REVENIUM_SKILL_PLUGIN_NAME"
+    ENV_REVENIUM_SKILL_SOURCE: str = "REVENIUM_SKILL_SOURCE"
     ENV_REVENIUM_OUTCOME_API_KEY: str = "REVENIUM_OUTCOME_API_KEY"
     ENV_REVENIUM_PROFITSTREAM_BASE_URL: str = "REVENIUM_PROFITSTREAM_BASE_URL"