> ## Documentation Index > Fetch the complete documentation index at: https://docs.withorb.com/llms.txt > Use this file to discover all available pages before exploring further. # Ingest events > Orb's event ingestion model and API is designed around two core principles: 1. **Data fidelity**: The accuracy of your billing model depends on a robust foundation of events. Orb's API protocol encourages usage patterns that ensure that your data is consistently complete and correct. 2. **Fast integration**: Sending events into Orb requires no tedious setup steps or explicit field schema for your event shape, making it instant to start streaming in usage in real-time. ## Event shape Events are the starting point for all usage calculations in the system, and are simple at their core: ```ts { // customer_id and external_customer_id are used to // attribute usage to a given Customer. Exactly one of these // should be specified in a given ingestion event. // `customer_id` is the Orb generated identifier for the Customer, // which is returned from the Create customer API call. customer_id: string, // external_customer_id is an alternate identifier which is associated // with a Customer at creation time. This is treated as an alias for // customer_id, and is usually set to an identifier native to your system. external_customer_id: string, // A string name identifying the event, usually a usage // action. By convention, this should not contain any whitespace. event_name: string, // An ISO 8601 format date with no timezone offset. // This should represent the time that usage occurred // and is important to attribute usage to a given // billing period. See the notes below on determining the timestamp. // e.g. 2020-12-09T16:09:53Z timestamp: string, // A unique value, generated by the client, that is // used to de-duplicate events. // Exactly one event with a given // idempotency key will be ingested, which allows for // safe request retries. idempotency_key: string // Optional custom metadata to attach to the event. // This might include a numeric value used for aggregation, // or a string/boolean value used for filtering. // The schema of this dictionary need not be pre-declared, and // properties can be added at any time. properties: { [key: string]?: string | number | boolean, }, } ``` ## Required fields Because events streamed to Orb are meant to be as flexible as possible, there are only a few required fields in every event. - We recommend that `idempotency_key` are unique strings that you generated with V4 UUIDs, but only require that they uniquely identify an event (i.e. don’t collide). - The `timestamp` field in the event body will be used to determine which billable period a given event falls into. For example, with a monthly billing cycle starting from the first of December, Orb will calculate metrics based on events that fall into the range `12-01 00:00:00 <= timestamp < 01-01 00:00:00`. ## Logging metadata Orb allows tagging events with metadata using a flexible properties dictionary. Since Orb does not enforce a rigid schema for this field-set, key-value pairs can be added dynamically as your events evolve. This dictionary can be helpful for a wide variety of use cases: - Numeric properties on events like `compute_time_ms` can later be inputs to our flexible query engine to determine usage. - Logging a region or cluster with each event can help you provide customers more granular visibility into their usage. - If you are using matrix pricing and matching a matrix price key with a property, you should ensure the value for that property is sent as a string. We encourage logging this metadata with an eye towards future use cases to ensure full coverage for historical data. The datatype of the value in the properties dictionary is important for metric creation from an event source. Values that you wish to numerically aggregate should be of numeric type in the event. ## Determining event timestamp For cases where usage is being reported in real time as it is occurring, timestamp should correspond to the time that usage occurred. In cases where usage is reported in aggregate for a historical timeframe at a regular interval, we recommend setting the event `timestamp` to the midpoint of the interval. As an example, if you have an hourly reporter that sends data once an hour for the previous hour of usage, setting the `timestamp` to the half-hour mark will ensure that the usage is counted within the correct period. Note that other time-related fields (e.g. time elapsed) can be added to the properties dictionary as necessary. In cases where usage is reported in aggregate for a historical timeframe, the timestamp must be within the grace period set for your account. Events with `timestamp < current_time - grace_period` will not be accepted as a valid event, and will throw validation errors. Enforcing the grace period enables Orb to accurately map usage to the correct billing cycle and ensure that all usage is billed for in the corresponding billing period. In general, Orb does not expect events with future dated timestamps. In cases where the timestamp is 5 minutes ahead of the current time, the event will not be accepted as a valid event, and will throw validation errors. ## Event validation Orb’s validation ensures that you recognize errors in your events as quickly as possible, and the API provides informative error messages to help you fix problems quickly. We validate the following: - Exactly one of `customer_id` and `external_customer_id` should be specified. - If the `customer_id` is specified, the customer in Orb must exist. - If the `external_customer_id` is specified, the customer in Orb does not need to exist. Events will be attributed to any future customers with the `external_customer_id` on subscription creation. - `timestamp` must conform to ISO 8601 and represent a timestamp at most 5 minutes in the future. This timestamp should be sent in UTC timezone (no timezone offset). ## Idempotency and retry semantics Orb's idempotency guarantees allow you to implement safe retry logic in the event of network or machine failures, ensuring data fidelity. Each event in the request payload is associated with an idempotency key, and Orb guarantees that a single idempotency key will be successfully ingested at most once. Note that when Orb encounters events with duplicate idempotency keys and differing event bodies in a batch of events, the entire batch will be rejected. - Successful responses return a 200 HTTP status code. The response contains information about previously processed events. - Requests that return a `4xx` HTTP status code indicate a payload error and contain at least one event with a validation failure. An event with a validation failure can be re-sent to the ingestion endpoint (after the payload is fixed) with the original idempotency key since that key is not marked as processed. - Requests that return a `5xx` HTTP status code indicate a server-side failure. These requests should be retried in their entirety. ## API usage and limits The ingestion API is designed made for real-time streaming ingestion and architected for high throughput. Even if events are later deemed unnecessary or filtered out, we encourage you to log them to Orb if they may be relevant to billing calculations in the future. To take advantage of the real-time features of the Orb platform and avoid any chance of dropped events by producers, we recommend reporting events to Orb frequently. Optionally, events can also be briefly aggregated at the source, as this API accepts an array of event bodies. Orb does not currently enforce a hard rate-limit for API usage or a maximum request payload size, but please give us a heads up if you’re changing either of these factors by an order of magnitude from initial setup. #### Example: ingestion response ```json { "validation_failed": [] } ``` ## OpenAPI ````yaml /api-reference/orb-openapi.json post /ingest openapi: 3.1.0 info: title: API Reference description: >- Orb's API is built with the following principles in mind: 1. **Predictable developer experience**: Where applicable, the Orb API uses industry-standard patterns such as cursor-based pagination and standardized error output. To help with debugging in critical API actions, the API always strives to provide detailed and actionable error messages. Aliases such as external customer IDs aid in fast integration times. 2. **Reliably real time**: Orb's event-based APIs, such as event ingestion are designed to handle extremely high throughput and scale with concurrent load. Orb also provides a real-time event-level credits ledger and a highly performant webhooks architecture. 3. **Flexibility at the forefront**: Features like timezone localization and the ability to amend historical usage show the flexible nature of the platform. You can download the latest OpenAPI spec [here](https://api.withorb.com/spec.json) - pass `?version=3.0` for an OpenAPI 3.0-compatible spec. contact: name: Orb, Inc. url: https://www.withorb.com/ email: team@withorb.com version: '1.0' servers: - url: https://api.withorb.com/v1 description: Production server security: - APIKeyAuth: [] tags: - name: Alert description: >- [Alerts within Orb](/product-catalog/configuring-alerts) monitor spending, usage, or credit balance and trigger webhooks when a threshold is exceeded. Alerts created through the API can be scoped to either customers or subscriptions. - name: Availability - name: Coupon description: >- A coupon represents a reusable discount configuration that can be applied either as a fixed or percentage amount to an invoice or subscription. Coupons are activated using a redemption code, which applies the discount to a subscription or invoice. The duration of a coupon determines how long it remains available for use by end users. - name: Credit description: >- The [Credit Ledger Entry resource](/product-catalog/prepurchase) models prepaid credits within Orb. - name: Credit note description: >- The [Credit Note](/invoicing/credit-notes) resource represents a credit that has been applied to a particular invoice. - name: Customer description: >- A customer is a buyer of your products, and the other party to the billing relationship. In Orb, customers are assigned system generated identifiers automatically, but it's often desirable to have these match existing identifiers in your system. To avoid having to denormalize Orb ID information, you can pass in an `external_customer_id` with your own identifier. See [Customer ID Aliases](/events-and-metrics/customer-aliases) for further information about how these aliases work in Orb. In addition to having an identifier in your system, a customer may exist in a payment provider solution like Stripe. Use the `payment_provider_id` and the `payment_provider` enum field to express this mapping. A customer also has a timezone (from the standard [IANA timezone database](https://www.iana.org/time-zones)), which defaults to your account's timezone. See [Timezone localization](/essentials/timezones) for information on what this timezone parameter influences within Orb. - name: Dimensional Price Group - name: Event description: >- The [Event](/core-concepts#event) resource represents a usage event that has been created for a customer. Events are the core of Orb's usage-based billing model, and are used to calculate the usage charges for a given billing period. - name: Invoice description: >- An [`Invoice`](/core-concepts#invoice) is a fundamental billing entity, representing the request for payment for a single subscription. This includes a set of line items, which correspond to prices in the subscription's plan and can represent fixed recurring fees or usage-based fees. They are generated at the end of a billing period, or as the result of an action, such as a cancellation. - name: Item description: >- The Item resource represents a sellable product or good. Items are associated with all line items, billable metrics, and prices and are used for defining external sync behavior for invoices and tax calculation purposes. - name: License - name: LicenseType description: >- The LicenseType resource represents a type of license that can be assigned to users. License types are used during billing by grouping metrics on the configured grouping key. - name: Metric description: >- The Metric resource represents a calculation of a quantity based on events. Metrics are defined by the query that transforms raw usage events into meaningful values for your customers. - name: Plan description: >- The [Plan](/core-concepts#plan-and-price) resource represents a plan that can be subscribed to by a customer. Plans define the billing behavior of the subscription. You can see more about how to configure prices in the [Price resource](/reference/price). - name: Price description: >- The Price resource represents a price that can be billed on a subscription, resulting in a charge on an invoice in the form of an invoice line item. Prices take a quantity and determine an amount to bill. Orb supports a few different pricing models out of the box. Each of these models is serialized differently in a given Price object. The model_type field determines the key for the configuration object that is present. For more on the types of prices, see [the core concepts documentation](/core-concepts#plan-and-price) - name: Price interval description: >- The Price Interval resource represents a period of time for which a price will bill on a subscription. A subscription’s price intervals define its billing behavior. - name: Subscription description: >- A [subscription](/core-concepts#subscription) represents the purchase of a plan by a customer. By default, subscriptions begin on the day that they're created and renew automatically for each billing cycle at the cadence that's configured in the plan definition. Subscriptions also default to **beginning of month alignment**, which means the first invoice issued for the subscription will have pro-rated charges between the `start_date` and the first of the following month. Subsequent billing periods will always start and end on a month boundary (e.g. subsequent month starts for monthly billing). Depending on the plan configuration, any _flat_ recurring fees will be billed either at the beginning (in-advance) or end (in-arrears) of each billing cycle. Plans default to **in-advance billing**. Usage-based fees are billed in arrears as usage is accumulated. In the normal course of events, you can expect an invoice to contain usage-based charges for the previous period, and a recurring fee for the following period. - name: Subscription Change paths: /ingest: post: tags: - Event summary: Ingest events description: >- Orb's event ingestion model and API is designed around two core principles: 1. **Data fidelity**: The accuracy of your billing model depends on a robust foundation of events. Orb's API protocol encourages usage patterns that ensure that your data is consistently complete and correct. 2. **Fast integration**: Sending events into Orb requires no tedious setup steps or explicit field schema for your event shape, making it instant to start streaming in usage in real-time. ## Event shape Events are the starting point for all usage calculations in the system, and are simple at their core: ```ts { // customer_id and external_customer_id are used to // attribute usage to a given Customer. Exactly one of these // should be specified in a given ingestion event. // `customer_id` is the Orb generated identifier for the Customer, // which is returned from the Create customer API call. customer_id: string, // external_customer_id is an alternate identifier which is associated // with a Customer at creation time. This is treated as an alias for // customer_id, and is usually set to an identifier native to your system. external_customer_id: string, // A string name identifying the event, usually a usage // action. By convention, this should not contain any whitespace. event_name: string, // An ISO 8601 format date with no timezone offset. // This should represent the time that usage occurred // and is important to attribute usage to a given // billing period. See the notes below on determining the timestamp. // e.g. 2020-12-09T16:09:53Z timestamp: string, // A unique value, generated by the client, that is // used to de-duplicate events. // Exactly one event with a given // idempotency key will be ingested, which allows for // safe request retries. idempotency_key: string // Optional custom metadata to attach to the event. // This might include a numeric value used for aggregation, // or a string/boolean value used for filtering. // The schema of this dictionary need not be pre-declared, and // properties can be added at any time. properties: { [key: string]?: string | number | boolean, }, } ``` ## Required fields Because events streamed to Orb are meant to be as flexible as possible, there are only a few required fields in every event. - We recommend that `idempotency_key` are unique strings that you generated with V4 UUIDs, but only require that they uniquely identify an event (i.e. don’t collide). - The `timestamp` field in the event body will be used to determine which billable period a given event falls into. For example, with a monthly billing cycle starting from the first of December, Orb will calculate metrics based on events that fall into the range `12-01 00:00:00 <= timestamp < 01-01 00:00:00`. ## Logging metadata Orb allows tagging events with metadata using a flexible properties dictionary. Since Orb does not enforce a rigid schema for this field-set, key-value pairs can be added dynamically as your events evolve. This dictionary can be helpful for a wide variety of use cases: - Numeric properties on events like `compute_time_ms` can later be inputs to our flexible query engine to determine usage. - Logging a region or cluster with each event can help you provide customers more granular visibility into their usage. - If you are using matrix pricing and matching a matrix price key with a property, you should ensure the value for that property is sent as a string. We encourage logging this metadata with an eye towards future use cases to ensure full coverage for historical data. The datatype of the value in the properties dictionary is important for metric creation from an event source. Values that you wish to numerically aggregate should be of numeric type in the event. ## Determining event timestamp For cases where usage is being reported in real time as it is occurring, timestamp should correspond to the time that usage occurred. In cases where usage is reported in aggregate for a historical timeframe at a regular interval, we recommend setting the event `timestamp` to the midpoint of the interval. As an example, if you have an hourly reporter that sends data once an hour for the previous hour of usage, setting the `timestamp` to the half-hour mark will ensure that the usage is counted within the correct period. Note that other time-related fields (e.g. time elapsed) can be added to the properties dictionary as necessary. In cases where usage is reported in aggregate for a historical timeframe, the timestamp must be within the grace period set for your account. Events with `timestamp < current_time - grace_period` will not be accepted as a valid event, and will throw validation errors. Enforcing the grace period enables Orb to accurately map usage to the correct billing cycle and ensure that all usage is billed for in the corresponding billing period. In general, Orb does not expect events with future dated timestamps. In cases where the timestamp is 5 minutes ahead of the current time, the event will not be accepted as a valid event, and will throw validation errors. ## Event validation Orb’s validation ensures that you recognize errors in your events as quickly as possible, and the API provides informative error messages to help you fix problems quickly. We validate the following: - Exactly one of `customer_id` and `external_customer_id` should be specified. - If the `customer_id` is specified, the customer in Orb must exist. - If the `external_customer_id` is specified, the customer in Orb does not need to exist. Events will be attributed to any future customers with the `external_customer_id` on subscription creation. - `timestamp` must conform to ISO 8601 and represent a timestamp at most 5 minutes in the future. This timestamp should be sent in UTC timezone (no timezone offset). ## Idempotency and retry semantics Orb's idempotency guarantees allow you to implement safe retry logic in the event of network or machine failures, ensuring data fidelity. Each event in the request payload is associated with an idempotency key, and Orb guarantees that a single idempotency key will be successfully ingested at most once. Note that when Orb encounters events with duplicate idempotency keys and differing event bodies in a batch of events, the entire batch will be rejected. - Successful responses return a 200 HTTP status code. The response contains information about previously processed events. - Requests that return a `4xx` HTTP status code indicate a payload error and contain at least one event with a validation failure. An event with a validation failure can be re-sent to the ingestion endpoint (after the payload is fixed) with the original idempotency key since that key is not marked as processed. - Requests that return a `5xx` HTTP status code indicate a server-side failure. These requests should be retried in their entirety. ## API usage and limits The ingestion API is designed made for real-time streaming ingestion and architected for high throughput. Even if events are later deemed unnecessary or filtered out, we encourage you to log them to Orb if they may be relevant to billing calculations in the future. To take advantage of the real-time features of the Orb platform and avoid any chance of dropped events by producers, we recommend reporting events to Orb frequently. Optionally, events can also be briefly aggregated at the source, as this API accepts an array of event bodies. Orb does not currently enforce a hard rate-limit for API usage or a maximum request payload size, but please give us a heads up if you’re changing either of these factors by an order of magnitude from initial setup. #### Example: ingestion response ```json { "validation_failed": [] } ``` operationId: ingest parameters: - required: false style: form schema: type: boolean title: Debug description: >- Pending Deprecation: Flag to enable additional debug information in the endpoint response default: false deprecated: true name: debug in: query - required: false style: form schema: oneOf: - type: string - type: 'null' title: Backfill Id description: >- If this ingestion request is part of a backfill, this parameter ties the ingested events to the backfill name: backfill_id in: query requestBody: content: application/json: schema: $ref: '#/components/schemas/IngestRequestBody' required: true responses: '200': description: OK headers: {} content: application/json: schema: $ref: '#/components/schemas/IngestionResponse' '400': description: Bad Request headers: {} content: application/json: schema: $ref: '#/components/schemas/400Error' '401': description: Unauthorized headers: {} content: application/json: schema: $ref: '#/components/schemas/401Error' '404': description: Not Found headers: {} content: application/json: schema: $ref: '#/components/schemas/404Error' '409': description: Conflict headers: {} content: application/json: schema: $ref: '#/components/schemas/409Error' '413': description: Content Too Large headers: {} content: application/json: schema: $ref: '#/components/schemas/413Error' '429': description: Too Many Requests headers: {} content: application/json: schema: $ref: '#/components/schemas/429Error' '500': description: Internal Server Error headers: {} content: application/json: schema: $ref: '#/components/schemas/500Error' components: schemas: IngestRequestBody: properties: events: items: properties: customer_id: oneOf: - type: string - type: 'null' title: Customer Id description: The Orb Customer identifier external_customer_id: oneOf: - type: string - type: 'null' title: External Customer Id description: >- An alias for the Orb customer, whose mapping is specified when creating the customer event_name: type: string title: Event Name description: A name to meaningfully identify the action or event type. timestamp: type: string format: date-time title: Timestamp description: >- An ISO 8601 format date with no timezone offset (i.e. UTC). This should represent the time that usage was recorded, and is particularly important to attribute usage to a given billing period. examples: - '2020-12-09T16:09:53Z' properties: additionalProperties: true type: object title: Properties description: >- A dictionary of custom properties. Values in this dictionary must be numeric, boolean, or strings. Nested dictionaries are disallowed. idempotency_key: type: string title: Idempotency Key description: >- A unique value, generated by the client, that is used to de-duplicate events. Exactly one event with a given idempotency key will be ingested, which allows for safe request retries. additionalProperties: false type: object required: - event_name - timestamp - properties - idempotency_key title: IngestEvent type: array title: Events additionalProperties: false type: object required: - events title: IngestRequestBody IngestionResponse: properties: debug: oneOf: - $ref: '#/components/schemas/Debug' - type: 'null' description: >- Optional debug information (only present when debug=true is passed to the endpoint). Contains ingested and duplicate event idempotency keys. validation_failed: items: $ref: '#/components/schemas/ValidationError' type: array title: Validation Failed description: >- Contains all failing validation events. In the case of a 200, this array will always be empty. This field will always be present. type: object required: - validation_failed title: IngestionResponse 400Error: oneOf: - $ref: '#/components/schemas/ConstraintViolationError' - $ref: '#/components/schemas/DuplicateResourceCreationError' - $ref: '#/components/schemas/RequestValidationError' 401Error: $ref: '#/components/schemas/AuthorizationError' title: 401Error 404Error: oneOf: - $ref: '#/components/schemas/FeatureNotAvailableError' - $ref: '#/components/schemas/ResourceNotFoundError' - $ref: '#/components/schemas/URLNotFound' 409Error: $ref: '#/components/schemas/IdempotencyRequestMismatch' title: 409Error 413Error: oneOf: - $ref: '#/components/schemas/RequestTooLargeError' - $ref: '#/components/schemas/ResourceTooLargeError' - $ref: '#/components/schemas/TooManyResultsError' 429Error: $ref: '#/components/schemas/TooManyRequests' title: 429Error 500Error: $ref: '#/components/schemas/ServerError' title: 500Error Debug: properties: duplicate: items: type: string type: array title: Duplicate ingested: items: type: string type: array title: Ingested type: object required: - duplicate - ingested title: Debug ValidationError: properties: idempotency_key: type: string title: Idempotency Key description: The passed idempotency_key corresponding to the validation_errors validation_errors: items: type: string type: array title: Validation Errors description: >- An array of strings corresponding to validation failures for this idempotency_key. type: object required: - idempotency_key - validation_errors title: ValidationError ConstraintViolationError: properties: type: type: string enum: - >- https://docs.withorb.com/reference/error-responses#400-constraint-violation title: Type status: type: integer enum: - 400 title: Status detail: oneOf: - type: string - type: 'null' title: Detail title: oneOf: - type: string - type: 'null' title: Title type: object required: - type - status title: ConstraintViolationError DuplicateResourceCreationError: properties: type: type: string enum: - >- https://docs.withorb.com/reference/error-responses#400-duplicate-resource-creation title: Type status: type: integer enum: - 400 title: Status detail: oneOf: - type: string - type: 'null' title: Detail title: oneOf: - type: string - type: 'null' title: Title type: object required: - type - status title: DuplicateResourceCreationError RequestValidationError: properties: type: type: string enum: - >- https://docs.withorb.com/reference/error-responses#400-request-validation-errors title: Type status: type: integer enum: - 400 title: Status detail: oneOf: - type: string - type: 'null' title: Detail title: oneOf: - type: string - type: 'null' title: Title validation_errors: items: {} type: array title: Validation Errors type: object required: - type - status - validation_errors title: RequestValidationError AuthorizationError: properties: type: type: string enum: - >- https://docs.withorb.com/reference/error-responses#401-authentication-error title: Type status: type: integer enum: - 401 title: Status detail: oneOf: - type: string - type: 'null' title: Detail title: oneOf: - type: string - type: 'null' title: Title type: object required: - type - status title: AuthorizationError FeatureNotAvailableError: properties: type: type: string enum: - >- https://docs.withorb.com/reference/error-responses#404-feature-not-available title: Type status: type: integer enum: - 400 title: Status detail: oneOf: - type: string - type: 'null' title: Detail title: oneOf: - type: string - type: 'null' title: Title type: object required: - type - status title: FeatureNotAvailableError ResourceNotFoundError: properties: type: type: string enum: - >- https://docs.withorb.com/reference/error-responses#404-resource-not-found title: Type status: type: integer enum: - 404 title: Status detail: oneOf: - type: string - type: 'null' title: Detail title: type: string title: Title type: object required: - type - status - title title: ResourceNotFoundError URLNotFound: properties: type: type: string enum: - >- https://docs.withorb.com/reference/error-responses#404-url-not-found title: Type status: type: integer enum: - 404 title: Status detail: oneOf: - type: string - type: 'null' title: Detail title: oneOf: - type: string - type: 'null' title: Title type: object required: - type - status title: URLNotFound IdempotencyRequestMismatch: properties: type: type: string enum: - >- https://docs.withorb.com/reference/error-responses#409-resource-conflict title: Type status: type: integer enum: - 409 title: Status detail: oneOf: - type: string - type: 'null' title: Detail title: oneOf: - type: string - type: 'null' title: Title type: object required: - type - status title: IdempotencyRequestMismatch RequestTooLargeError: properties: type: type: string enum: - >- https://docs.withorb.com/reference/error-responses#413-request-too-large title: Type status: type: integer enum: - 413 title: Status detail: oneOf: - type: string - type: 'null' title: Detail title: oneOf: - type: string - type: 'null' title: Title type: object required: - type - status title: RequestTooLargeError ResourceTooLargeError: properties: type: type: string enum: - >- https://docs.withorb.com/reference/error-responses#413-resource-too-large title: Type status: type: integer enum: - 413 title: Status detail: oneOf: - type: string - type: 'null' title: Detail title: oneOf: - type: string - type: 'null' title: Title type: object required: - type - status title: ResourceTooLargeError TooManyResultsError: properties: type: type: string enum: - >- https://docs.withorb.com/reference/error-responses#413-too-many-results title: Type status: type: integer enum: - 413 title: Status detail: oneOf: - type: string - type: 'null' title: Detail title: oneOf: - type: string - type: 'null' title: Title type: object required: - type - status title: TooManyResultsError TooManyRequests: properties: type: type: string enum: - >- https://docs.withorb.com/reference/error-responses#429-too-many-requests title: Type status: type: integer enum: - 429 title: Status detail: oneOf: - type: string - type: 'null' title: Detail title: oneOf: - type: string - type: 'null' title: Title type: object required: - type - status title: TooManyRequests ServerError: properties: type: type: string enum: - >- https://docs.withorb.com/reference/error-responses#500-internal-server-error title: Type status: type: integer title: Status detail: oneOf: - type: string - type: 'null' title: Detail title: oneOf: - type: string - type: 'null' title: Title type: object required: - type - status title: ServerError securitySchemes: APIKeyAuth: type: http description: API Keys can be issued in the Orb's web application. scheme: bearer ````