add guide to demonstrate different ways to bill with ubb #112
Conversation
WalkthroughAdds a new MDX guide "Different ways to bill with Usage Based Billing" describing three billing bases (API calls, token usage, runtime) with step-by-step meter creation flows, ingest examples (JavaScript/Python/curl), filtering/grouping guidance, and adds the page to navigation under Developer Resources → Integration Guides. Changes
Sequence Diagram(s)sequenceDiagram
autonumber
actor User
participant Docs as "Docs Site"
participant UI as "Meter Builder UI"
participant API as "Events API"
participant Billing as "Billing Engine"
User->>Docs: Open "Different ways to bill with UBB"
Docs-->>User: Render guide (API Calls / Tokens / Runtime)
User->>UI: Configure Meter (name, event_name, aggregation, unit, filters/groups)
alt Count (API calls)
Note right of UI #D6EAF8: aggregation = count\nrequired: event_name
UI->>Billing: Save meter (count configuration)
else Sum (Tokens)
Note right of UI #FDEBD0: aggregation = sum\nover token property\nunit = tokens
UI->>Billing: Save meter (sum on token property)
else Sum (Runtime)
Note right of UI #E8F8F5: aggregation = sum\nover execution_time\nunit = compute.hour
UI->>Billing: Save meter (sum on runtime)
end
User->>API: Ingest event (JS/Python/curl) with event_name and metadata
API->>Billing: Append event to meter aggregation
Billing-->>User: Metered usage available for billing/analysis
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes Poem
Pre-merge checks and finishing touches✅ Passed checks (5 passed)
✨ Finishing touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (3)
images/different-ways-to-bill-with-ubb/api-call-meter.pngis excluded by!**/*.pngimages/different-ways-to-bill-with-ubb/execution-time.pngis excluded by!**/*.pngimages/different-ways-to-bill-with-ubb/token-usage-meter.pngis excluded by!**/*.png
📒 Files selected for processing (2)
developer-resources/different-ways-to-bill-with-ubb.mdx(1 hunks)docs.json(1 hunks)
🧰 Additional context used
📓 Path-based instructions (2)
**/*.{md,mdx}
📄 CodeRabbit inference engine (.cursor/rules/mintlify.mdc)
Every documentation page must begin with YAML frontmatter containing title and description
Files:
developer-resources/different-ways-to-bill-with-ubb.mdx
**/*.mdx
📄 CodeRabbit inference engine (.cursor/rules/mintlify.mdc)
**/*.mdx: Use clear, direct language appropriate for technical audiences
Write instructions in second person (you)
Use active voice over passive voice
Use present tense for current states and future tense for outcomes
Maintain consistent terminology across documentation
Keep sentences concise while preserving necessary context
Use parallel structure in lists, headings, and procedures
Lead sections with the most important information (inverted pyramid)
Use progressive disclosure: introduce basics before advanced topics
Break complex procedures into numbered steps using /
Include prerequisites and context before instructions
Provide expected outcomes for each major step
End sections with next steps or related information
Use descriptive, keyword-rich headings for navigation and SEO
Focus on user goals and outcomes rather than system features
Anticipate common questions and address them proactively
Include troubleshooting for likely failure points
Provide multiple pathways (beginner vs advanced) when appropriate, with an opinionated recommended path
Use for supplementary information that supports main content
Use for expert advice, shortcuts, or best practices
Use for critical cautions, breaking changes, or destructive actions
Use for neutral background or contextual information
Use for success confirmations or achievement indicators
Use to present the same concept in multiple languages
Provide complete, runnable code examples with language specified and filename when relevant
Include RequestExample/ResponseExample blocks for API endpoint docs
Document API parameters using (path, query, header, body) with types and required/defaults
Document API responses using with names, types, and required flags
Use for nested object properties or hierarchical information
Use / for platform-specific or alternative approaches
Use / for suppl...
Files:
developer-resources/different-ways-to-bill-with-ubb.mdx
|
I can see couple of issues here.
2.Image not displayed under the below sub section. Can you please revisit this? Apart from configuration docs, this guide should provide actual use cases with some small code snippets for ingestion. |
|
made the changes, let me know if I missed something. |
There was a problem hiding this comment.
Actionable comments posted: 2
♻️ Duplicate comments (1)
developer-resources/different-ways-to-bill-with-ubb.mdx (1)
14-15: Rewrite instructions in second person active voice.Phrases such as “In this section you'll see…” still speak about the reader in third person, violating the MDX guideline that all procedural language must address the reader directly (“You…” / imperative). Please sweep the full guide and convert remaining instances to second-person active phrasing.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (1)
images/different-ways-to-bill-with-ubb/execution-time-meter.pngis excluded by!**/*.png
📒 Files selected for processing (1)
developer-resources/different-ways-to-bill-with-ubb.mdx(1 hunks)
🧰 Additional context used
📓 Path-based instructions (2)
**/*.{md,mdx}
📄 CodeRabbit inference engine (.cursor/rules/mintlify.mdc)
Every documentation page must begin with YAML frontmatter containing title and description
Files:
developer-resources/different-ways-to-bill-with-ubb.mdx
**/*.mdx
📄 CodeRabbit inference engine (.cursor/rules/mintlify.mdc)
**/*.mdx: Use clear, direct language appropriate for technical audiences
Write instructions in second person (you)
Use active voice over passive voice
Use present tense for current states and future tense for outcomes
Maintain consistent terminology across documentation
Keep sentences concise while preserving necessary context
Use parallel structure in lists, headings, and procedures
Lead sections with the most important information (inverted pyramid)
Use progressive disclosure: introduce basics before advanced topics
Break complex procedures into numbered steps using /
Include prerequisites and context before instructions
Provide expected outcomes for each major step
End sections with next steps or related information
Use descriptive, keyword-rich headings for navigation and SEO
Focus on user goals and outcomes rather than system features
Anticipate common questions and address them proactively
Include troubleshooting for likely failure points
Provide multiple pathways (beginner vs advanced) when appropriate, with an opinionated recommended path
Use for supplementary information that supports main content
Use for expert advice, shortcuts, or best practices
Use for critical cautions, breaking changes, or destructive actions
Use for neutral background or contextual information
Use for success confirmations or achievement indicators
Use to present the same concept in multiple languages
Provide complete, runnable code examples with language specified and filename when relevant
Include RequestExample/ResponseExample blocks for API endpoint docs
Document API parameters using (path, query, header, body) with types and required/defaults
Document API responses using with names, types, and required flags
Use for nested object properties or hierarchical information
Use / for platform-specific or alternative approaches
Use / for suppl...
Files:
developer-resources/different-ways-to-bill-with-ubb.mdx
🧠 Learnings (1)
📚 Learning: 2025-09-15T12:32:29.480Z
Learnt from: CR
PR: dodopayments/dodo-docs#0
File: .cursor/rules/mintlify.mdc:0-0
Timestamp: 2025-09-15T12:32:29.480Z
Learning: Applies to **/*.mdx : Write instructions in second person (you)
Applied to files:
developer-resources/different-ways-to-bill-with-ubb.mdx
🪛 Gitleaks (8.28.0)
developer-resources/different-ways-to-bill-with-ubb.mdx
[high] 188-190: Discovered a potential authorization token provided in a curl command header, which could compromise the curl accessed resource.
(curl-auth-header)
[high] 390-392: Discovered a potential authorization token provided in a curl command header, which could compromise the curl accessed resource.
(curl-auth-header)
[high] 597-599: Discovered a potential authorization token provided in a curl command header, which could compromise the curl accessed resource.
(curl-auth-header)
There was a problem hiding this comment.
Actionable comments posted: 1
♻️ Duplicate comments (4)
developer-resources/different-ways-to-bill-with-ubb.mdx (4)
246-264: Make the aggregation property match the examples.Line 249 still says “go wtih” and the paragraph tells readers to sum the
tokenfield, but every ingest sample usesmetadata.tokens. Following the current text would leave the meter summing a nonexistent property. Please fix the typo and align the configuration with the events.-Select how events should be aggregated: -To calculate the Token usage go wtih `Sum` type. +Select how events should be aggregated: +To calculate token usage go with the `Sum` type. … -<ParamField path="Over Property" type="string"> -The property name from event metadata to aggregate over. Here, aggregate it over `token` field. +<ParamField path="Over Property" type="string"> +The property name from event metadata to aggregate over. Here, aggregate it over the `tokens` field. … -Example: "token" +Example: "tokens"
397-410: Fix the token cURL sample JSON.
metadataandtokensaren’t quoted, and the timestamp is not valid ISO 8601 (“2025-10-8…”). As written the payload won’t parse. Quote the keys and fix the timestamp so the example works.- "event_name": "token", - "timestamp": "2025-10-8T10:30:00Z", - metadata: { - tokens: 100 - } + "event_name": "token", + "timestamp": "2025-10-08T10:30:00Z", + "metadata": { + "tokens": 100 + }
458-501: Use a singleruntimeproperty throughout the runtime flow.This section still tells readers to sum an
hourfield, while the filter examples mentionexecution_time/hours. That mismatch was raised earlier and remains confusing—users will aggregate the wrong property. Align the guidance on Lines 459–500 so everything referencesmetadata.runtimeconsistently.-Select how events should be aggregated: -To calculate the Runtime go wtih `Sum` type. +Select how events should be aggregated: +To calculate runtime go with the `Sum` type. … -<ParamField path="Over Property" type="string"> -The property name from event metadata to aggregate over. Here, aggregate it over `hour` field. +<ParamField path="Over Property" type="string"> +The property name from event metadata to aggregate over. Here, aggregate it over the `runtime` field. … -**Example:** Count compute hours where `execution_time > 60` **AND** `model_type = "advanced"` +**Example:** Count runtime events where `metadata.runtime > 60` **AND** `metadata.model_type = "advanced"` … -**Example:** Count compute hours where `hours > 60` **OR** `model_type = "advanced"` +**Example:** Count runtime events where `metadata.runtime > 60` **OR** `metadata.model_type = "advanced"`
565-620: Fix runtime ingest samples (property and JSON).All three samples still send
metadata.hour, and the cURL block keeps the invalid JSON noted earlier. To match the meter text and avoid parse errors, sendmetadata.runtimeand ensure the JSON is valid.- metadata: { - hour: 60 - } + metadata: { + runtime: 3600 + }- 'metadata': { - 'hour': 60 - } + 'metadata': { + 'runtime': 3600 + }- "event_name": "compute.hour", - "timestamp": "2025-10-8T10:30:00Z", - metadata: { - hour: 60 - } + "event_name": "compute.hour", + "timestamp": "2025-10-08T10:30:00Z", + "metadata": { + "runtime": 3600 + }
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
developer-resources/different-ways-to-bill-with-ubb.mdx(1 hunks)
🧰 Additional context used
📓 Path-based instructions (2)
**/*.{md,mdx}
📄 CodeRabbit inference engine (.cursor/rules/mintlify.mdc)
Every documentation page must begin with YAML frontmatter containing title and description
Files:
developer-resources/different-ways-to-bill-with-ubb.mdx
**/*.mdx
📄 CodeRabbit inference engine (.cursor/rules/mintlify.mdc)
**/*.mdx: Use clear, direct language appropriate for technical audiences
Write instructions in second person (you)
Use active voice over passive voice
Use present tense for current states and future tense for outcomes
Maintain consistent terminology across documentation
Keep sentences concise while preserving necessary context
Use parallel structure in lists, headings, and procedures
Lead sections with the most important information (inverted pyramid)
Use progressive disclosure: introduce basics before advanced topics
Break complex procedures into numbered steps using /
Include prerequisites and context before instructions
Provide expected outcomes for each major step
End sections with next steps or related information
Use descriptive, keyword-rich headings for navigation and SEO
Focus on user goals and outcomes rather than system features
Anticipate common questions and address them proactively
Include troubleshooting for likely failure points
Provide multiple pathways (beginner vs advanced) when appropriate, with an opinionated recommended path
Use for supplementary information that supports main content
Use for expert advice, shortcuts, or best practices
Use for critical cautions, breaking changes, or destructive actions
Use for neutral background or contextual information
Use for success confirmations or achievement indicators
Use to present the same concept in multiple languages
Provide complete, runnable code examples with language specified and filename when relevant
Include RequestExample/ResponseExample blocks for API endpoint docs
Document API parameters using (path, query, header, body) with types and required/defaults
Document API responses using with names, types, and required flags
Use for nested object properties or hierarchical information
Use / for platform-specific or alternative approaches
Use / for suppl...
Files:
developer-resources/different-ways-to-bill-with-ubb.mdx
🧠 Learnings (1)
📚 Learning: 2025-09-15T12:32:29.480Z
Learnt from: CR
PR: dodopayments/dodo-docs#0
File: .cursor/rules/mintlify.mdc:0-0
Timestamp: 2025-09-15T12:32:29.480Z
Learning: Applies to **/*.mdx : Write instructions in second person (you)
Applied to files:
developer-resources/different-ways-to-bill-with-ubb.mdx
🪛 Gitleaks (8.28.0)
developer-resources/different-ways-to-bill-with-ubb.mdx
[high] 188-190: Discovered a potential authorization token provided in a curl command header, which could compromise the curl accessed resource.
(curl-auth-header)
[high] 396-398: Discovered a potential authorization token provided in a curl command header, which could compromise the curl accessed resource.
(curl-auth-header)
[high] 606-608: Discovered a potential authorization token provided in a curl command header, which could compromise the curl accessed resource.
(curl-auth-header)
There was a problem hiding this comment.
Actionable comments posted: 1
♻️ Duplicate comments (4)
developer-resources/different-ways-to-bill-with-ubb.mdx (4)
12-16: Voice largely fixed to second person—nice work.Tone matches guidelines; consider trimming “In this section you'll see…” to imperative (“Configure…”, “Charge based on…”).
Also applies to: 206-210, 417-421
252-264: Align Over Property and unit naming for token aggregation.You aggregate over “token” but examples send “tokens”. Pick one; recommend “tokens” (plural) to match examples and unit.
-<ParamField path="Over Property" type="string"> -The property name from event metadata to aggregate over. Here, aggregate it over `token` field. +<ParamField path="Over Property" type="string"> +The property name from event metadata to aggregate over. Aggregate over the `tokens` property. @@ -Example: "token" +Example: "tokens"
397-413: Fix invalid JSON in cURL examples (unquoted keys in metadata).Keys must be quoted; current payloads will fail.
-d '{ "events": [ { "event_id": "token_usage_1234", "customer_id": "cust_id_123", "event_name": "token", - "timestamp": "2025-10-8T10:30:00Z", - metadata: { - tokens: 100 - } + "timestamp": "2025-10-08T10:30:00Z", + "metadata": { + "tokens": 100 + } } ] }'-d '{ "events": [ { "event_id": "compute_hour_1234", "customer_id": "cust_id_123", "event_name": "compute.hour", - "timestamp": "2025-10-8T10:30:00Z", - metadata: { - hour: 60 - } + "timestamp": "2025-10-08T10:30:00Z", + "metadata": { + "hours": 60 + } } ] }'Also applies to: 606-623
463-475: Standardize the runtime property name across config, filters, and samples.Use one property name consistently. Recommend “hours” to match Measurement Unit.
-<ParamField path="Over Property" type="string"> -The property name from event metadata to aggregate over. Here, aggregate it over `hour` field. +<ParamField path="Over Property" type="string"> +Aggregate over the `hours` property.-**Example:** Count compute hours where `execution_time > 60` **AND** `model_type = "advanced"` +**Example:** Count compute hours where `hours > 60` **AND** `model_type = "advanced"` @@ -**Example:** Count compute hours where `hours > 60` **OR** `model_type = "advanced"` +**Example:** Count compute hours where `hours > 60` **OR** `model_type = "advanced"`- metadata: { - hour: 60 - } + metadata: { + hours: 60 + }- 'metadata': { - 'hour': 60 - } + 'metadata': { + 'hours': 60 + }- metadata: { - hour: 60 - } + metadata: { + hours: 60 + }Also applies to: 494-501, 571-574, 598-599, 617-619
🧹 Nitpick comments (3)
developer-resources/different-ways-to-bill-with-ubb.mdx (3)
189-191: Use safer API key placeholders to avoid secret scanner noise.Prefer angle-bracket placeholders or env substitution.
- -H 'Authorization: Bearer YOUR_API_KEY' \ + -H 'Authorization: Bearer <YOUR_API_KEY>' \Alternatively:
- -H 'Authorization: Bearer YOUR_API_KEY' \ + -H "Authorization: Bearer ${DODO_API_KEY}" \Also applies to: 397-399, 607-609
165-186: Make Python examples runnable (define api_key).Define api_key from env before the request.
-import requests +import os, requests from datetime import datetime + +api_key = os.getenv("DODO_API_KEY", "YOUR_API_KEY")Optional: check response status and print body for verification.
Also applies to: 370-394, 580-604
140-205: Add a minimal ResponseExample for ingest.Show expected HTTP status and a sample response to help users verify success.
For example:
- Status: 202 Accepted
- Body: {"status":"accepted","accepted":1,"failed":0}
Also applies to: 342-416, 552-624
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
developer-resources/different-ways-to-bill-with-ubb.mdx(1 hunks)
🧰 Additional context used
📓 Path-based instructions (2)
**/*.{md,mdx}
📄 CodeRabbit inference engine (.cursor/rules/mintlify.mdc)
Every documentation page must begin with YAML frontmatter containing title and description
Files:
developer-resources/different-ways-to-bill-with-ubb.mdx
**/*.mdx
📄 CodeRabbit inference engine (.cursor/rules/mintlify.mdc)
**/*.mdx: Use clear, direct language appropriate for technical audiences
Write instructions in second person (you)
Use active voice over passive voice
Use present tense for current states and future tense for outcomes
Maintain consistent terminology across documentation
Keep sentences concise while preserving necessary context
Use parallel structure in lists, headings, and procedures
Lead sections with the most important information (inverted pyramid)
Use progressive disclosure: introduce basics before advanced topics
Break complex procedures into numbered steps using /
Include prerequisites and context before instructions
Provide expected outcomes for each major step
End sections with next steps or related information
Use descriptive, keyword-rich headings for navigation and SEO
Focus on user goals and outcomes rather than system features
Anticipate common questions and address them proactively
Include troubleshooting for likely failure points
Provide multiple pathways (beginner vs advanced) when appropriate, with an opinionated recommended path
Use for supplementary information that supports main content
Use for expert advice, shortcuts, or best practices
Use for critical cautions, breaking changes, or destructive actions
Use for neutral background or contextual information
Use for success confirmations or achievement indicators
Use to present the same concept in multiple languages
Provide complete, runnable code examples with language specified and filename when relevant
Include RequestExample/ResponseExample blocks for API endpoint docs
Document API parameters using (path, query, header, body) with types and required/defaults
Document API responses using with names, types, and required flags
Use for nested object properties or hierarchical information
Use / for platform-specific or alternative approaches
Use / for suppl...
Files:
developer-resources/different-ways-to-bill-with-ubb.mdx
🧠 Learnings (1)
📚 Learning: 2025-09-15T12:32:29.480Z
Learnt from: CR
PR: dodopayments/dodo-docs#0
File: .cursor/rules/mintlify.mdc:0-0
Timestamp: 2025-09-15T12:32:29.480Z
Learning: Applies to **/*.mdx : Write instructions in second person (you)
Applied to files:
developer-resources/different-ways-to-bill-with-ubb.mdx
🪛 Gitleaks (8.28.0)
developer-resources/different-ways-to-bill-with-ubb.mdx
[high] 188-190: Discovered a potential authorization token provided in a curl command header, which could compromise the curl accessed resource.
(curl-auth-header)
[high] 396-398: Discovered a potential authorization token provided in a curl command header, which could compromise the curl accessed resource.
(curl-auth-header)
[high] 606-608: Discovered a potential authorization token provided in a curl command header, which could compromise the curl accessed resource.
(curl-auth-header)
There was a problem hiding this comment.
Actionable comments posted: 2
♻️ Duplicate comments (1)
developer-resources/different-ways-to-bill-with-ubb.mdx (1)
606-623: Make the runtime cURL sample valid JSON.Same issue here: the
metadatablock lacks quotes aroundmetadataandhour, so the request body is invalid. Quote the keys to keep the example executable.- metadata: { - hour: 60 - } + "metadata": { + "hour": 60 + }
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
developer-resources/different-ways-to-bill-with-ubb.mdx(1 hunks)
🧰 Additional context used
📓 Path-based instructions (2)
**/*.{md,mdx}
📄 CodeRabbit inference engine (.cursor/rules/mintlify.mdc)
Every documentation page must begin with YAML frontmatter containing title and description
Files:
developer-resources/different-ways-to-bill-with-ubb.mdx
**/*.mdx
📄 CodeRabbit inference engine (.cursor/rules/mintlify.mdc)
**/*.mdx: Use clear, direct language appropriate for technical audiences
Write instructions in second person (you)
Use active voice over passive voice
Use present tense for current states and future tense for outcomes
Maintain consistent terminology across documentation
Keep sentences concise while preserving necessary context
Use parallel structure in lists, headings, and procedures
Lead sections with the most important information (inverted pyramid)
Use progressive disclosure: introduce basics before advanced topics
Break complex procedures into numbered steps using /
Include prerequisites and context before instructions
Provide expected outcomes for each major step
End sections with next steps or related information
Use descriptive, keyword-rich headings for navigation and SEO
Focus on user goals and outcomes rather than system features
Anticipate common questions and address them proactively
Include troubleshooting for likely failure points
Provide multiple pathways (beginner vs advanced) when appropriate, with an opinionated recommended path
Use for supplementary information that supports main content
Use for expert advice, shortcuts, or best practices
Use for critical cautions, breaking changes, or destructive actions
Use for neutral background or contextual information
Use for success confirmations or achievement indicators
Use to present the same concept in multiple languages
Provide complete, runnable code examples with language specified and filename when relevant
Include RequestExample/ResponseExample blocks for API endpoint docs
Document API parameters using (path, query, header, body) with types and required/defaults
Document API responses using with names, types, and required flags
Use for nested object properties or hierarchical information
Use / for platform-specific or alternative approaches
Use / for suppl...
Files:
developer-resources/different-ways-to-bill-with-ubb.mdx
🧠 Learnings (1)
📚 Learning: 2025-09-15T12:32:29.480Z
Learnt from: CR
PR: dodopayments/dodo-docs#0
File: .cursor/rules/mintlify.mdc:0-0
Timestamp: 2025-09-15T12:32:29.480Z
Learning: Applies to **/*.mdx : Write instructions in second person (you)
Applied to files:
developer-resources/different-ways-to-bill-with-ubb.mdx
🪛 Gitleaks (8.28.0)
developer-resources/different-ways-to-bill-with-ubb.mdx
[high] 188-190: Discovered a potential authorization token provided in a curl command header, which could compromise the curl accessed resource.
(curl-auth-header)
[high] 396-398: Discovered a potential authorization token provided in a curl command header, which could compromise the curl accessed resource.
(curl-auth-header)
[high] 606-608: Discovered a potential authorization token provided in a curl command header, which could compromise the curl accessed resource.
(curl-auth-header)
| <ParamField path="Over Property" type="string"> | ||
| The property name from event metadata to aggregate over. Here, aggregate it over `token` field. | ||
|
|
||
| <Warning> | ||
| This field is required when using Sum, Max, or Last aggregation types. | ||
| </Warning> | ||
| </ParamField> | ||
|
|
||
| <ParamField path="Measurement Unit" type="string" required> | ||
| Define the unit label for display purposes in reports and billing. | ||
|
|
||
| Example: "token" | ||
| </ParamField> | ||
| </Step> | ||
|
|
||
| <Step title="Configure Event Filtering (Optional)"> | ||
| Set up criteria to control which events are included in the meter. | ||
|
|
||
|
|
||
| **Enable Event Filtering** | ||
|
|
||
| Toggle **Enable Event Filtering** to activate conditional event processing. | ||
|
|
||
| **Choose Filter Logic** | ||
|
|
||
| Select how multiple conditions are evaluated | ||
|
|
||
| <Tabs> | ||
| <Tab title="AND Logic"> | ||
| All conditions must be true for an event to be counted. Use this when you need events to meet multiple strict criteria simultaneously. | ||
|
|
||
| **Example:** Count Token usage on `endpoint = "/v1/ai"` **AND** `user_plan = "pro"` | ||
| </Tab> | ||
|
|
||
| <Tab title="OR Logic"> | ||
| At least one condition must be true for an event to be counted. Use this when you want to include events that meet any of several criteria. | ||
|
|
||
| **Example:** Count Token usage on `endpoint = "/v1/ai"` **OR** `endpoint = "/v1/chat"` | ||
| </Tab> | ||
| </Tabs> | ||
|
|
||
| **Setting Up Filter Conditions** | ||
|
|
||
| <Steps> | ||
| <Step title="Add Condition"> | ||
| Click **Add condition** to create a new filter rule. | ||
| </Step> | ||
|
|
||
| <Step title="Configure Property Key"> | ||
| Specify the property name from your event metadata. | ||
| </Step> | ||
|
|
||
| <Step title="Select Comparator"> | ||
| Choose from available operators: | ||
| - `equals` - Exact match | ||
| - `not equals` - Exclusion filter | ||
| - `greater than` - Numeric comparison | ||
| - `greater than or equals` - Numeric comparison (inclusive) | ||
| - `less than` - Numeric comparison | ||
| - `less than or equals` - Numeric comparison (inclusive) | ||
| - `contains` - String contains substring | ||
| - `does not contain` - String exclusion filter | ||
| </Step> | ||
|
|
||
| <Step title="Set Comparison Value"> | ||
| Set the target value for comparison. | ||
| </Step> | ||
|
|
||
| <Step title="Add Groups"> | ||
| Use **Add Group** to create additional condition groups for complex logic. | ||
| </Step> | ||
| </Steps> | ||
|
|
||
|
|
||
| <Warning> | ||
| Filtered properties must be included in your event metadata for the conditions to work properly. Events missing required properties will be excluded from counting. | ||
| </Warning> | ||
| </Step> | ||
|
|
||
| <Step title="Create Meter"> | ||
| Review your meter configuration and click on **Create Meter**. | ||
|
|
||
| <Check> | ||
| Your meter is now ready to receive and aggregate usage events. | ||
| </Check> | ||
|
|
||
| </Step> | ||
| </Steps> | ||
|
|
||
|
|
||
| ### Ingest an Event | ||
|
|
||
| Ingest event to your configured meter using Events API: | ||
|
|
||
| <CodeGroup> | ||
| ```javascript Node.js | ||
| const response = await fetch('https://test.dodopayments.com/events/ingest', { | ||
| method: 'POST', | ||
| headers: { | ||
| 'Authorization': `Bearer ${process.env.DODO_API_KEY}`, | ||
| 'Content-Type': 'application/json' | ||
| }, | ||
| body: JSON.stringify({ | ||
| events: [ | ||
| { | ||
| event_id: "token_usage_1234", | ||
| customer_id: "cust_id_123", | ||
| event_name: "token", | ||
| timestamp: new Date().toISOString(), | ||
| metadata: { | ||
| tokens: 100 | ||
| } | ||
| } |
There was a problem hiding this comment.
Align the aggregation field name with the ingest payload.
You instruct readers to sum the token property, but every ingest example sends metadata.tokens. Following the doc as written would yield zero usage. Update the “Over Property” guidance (and any other references) to use the exact key that appears in the sample payloads, or rename the payload field so both sides match.
🤖 Prompt for AI Agents
In developer-resources/different-ways-to-bill-with-ubb.mdx around lines 252-364,
the doc tells readers to aggregate over a `token` property but the example
ingest payload uses `metadata.tokens`, causing a mismatch and zero usage; fix by
making the names consistent — either change the “Over Property” guidance (and
any other references) to `tokens` (or `metadata.tokens` if you want to be
explicit about the metadata path) or change all example payloads to use `token`
instead of `tokens`, and update any accompanying examples and warnings so the
aggregation key exactly matches the sample event payloads.
| ```curl cURL | ||
| curl -X POST 'https://test.dodopayments.com/events/ingest' \ | ||
| -H 'Authorization: Bearer YOUR_API_KEY' \ | ||
| -H 'Content-Type: application/json' \ | ||
| -d '{ | ||
| "events": [ | ||
| { | ||
| "event_id": "token_usage_1234", | ||
| "customer_id": "cust_id_123", | ||
| "event_name": "token", | ||
| "timestamp": "2025-10-8T10:30:00Z", | ||
| metadata: { | ||
| tokens: 100 | ||
| } | ||
| } | ||
| ] | ||
| }' | ||
| ``` |
There was a problem hiding this comment.
Fix the cURL payload JSON (missing quotes).
The metadata object uses bare keys (metadata: { tokens: 100 }), which is invalid JSON and will make this request fail. Quote the keys so the example is copy‑paste runnable.
- metadata: {
- tokens: 100
- }
+ "metadata": {
+ "tokens": 100
+ }📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| ```curl cURL | |
| curl -X POST 'https://test.dodopayments.com/events/ingest' \ | |
| -H 'Authorization: Bearer YOUR_API_KEY' \ | |
| -H 'Content-Type: application/json' \ | |
| -d '{ | |
| "events": [ | |
| { | |
| "event_id": "token_usage_1234", | |
| "customer_id": "cust_id_123", | |
| "event_name": "token", | |
| "timestamp": "2025-10-8T10:30:00Z", | |
| metadata: { | |
| tokens: 100 | |
| } | |
| } | |
| ] | |
| }' | |
| ``` |
🧰 Tools
🪛 Gitleaks (8.28.0)
[high] 396-398: Discovered a potential authorization token provided in a curl command header, which could compromise the curl accessed resource.
(curl-auth-header)
🤖 Prompt for AI Agents
In developer-resources/different-ways-to-bill-with-ubb.mdx around lines 396 to
413, the embedded cURL JSON payload is invalid because the object keys in the
nested metadata are unquoted; update the JSON so all property names are quoted
(e.g. "metadata": { "tokens": 100 }) and ensure the entire payload uses valid
JSON syntax so the example is copy-paste runnable.
2 participants
📋 Description
add guide to demonstrate different ways to bill with ubb
🎯 Type of Change
📖 What documentation does this PR affect?
✅ Checklist
mintlify devdocs.json(if applicable)🧪 Testing
📸 Screenshots (if applicable)
🔗 Related Issues
Closes #86
📝 Additional Notes
👥 Reviewers
@dodopayments/documentation-team
Summary by CodeRabbit