Class: ApiReference::EventApi
- Defined in:
- lib/api_reference/apis/event_api.rb
Overview
EventApi
Constant Summary
Constants inherited from BaseApi
Instance Attribute Summary
Attributes inherited from BaseApi
Instance Method Summary collapse
-
#amend_event(event_id, body) ⇒ ApiResponse
This endpoint is used to amend a single usage event with a given
event_id. -
#close_backfill(backfill_id) ⇒ ApiResponse
Closing a backfill makes the updated usage visible in Orb.
-
#create_backfill(body) ⇒ ApiResponse
Creating the backfill enables adding or replacing past events, even those that are older than the ingestion grace period.
-
#deprecate_event(event_id) ⇒ ApiResponse
This endpoint is used to deprecate a single usage event with a given
event_id. -
#fetch_backfill(backfill_id) ⇒ ApiResponse
This endpoint is used to fetch a backfill given an identifier.
-
#get_event_volume(timeframe_start, limit: 20, cursor: nil, timeframe_end: nil) ⇒ ApiResponse
This endpoint returns the event volume for an account in a paginated list format.
-
#ingest(body, debug: false, backfill_id: nil) ⇒ ApiResponse
Orb's event ingestion model and API is designed around two core principles: 1.
-
#list_backfills(limit: 20, cursor: nil) ⇒ ApiResponse
This endpoint returns a list of all backfills in a list format.
-
#revert_backfill(backfill_id) ⇒ ApiResponse
Reverting a backfill undoes all the effects of closing the backfill.
-
#search_events(body) ⇒ ApiResponse
This endpoint returns a filtered set of events for an account in a paginated list format.
Methods inherited from BaseApi
#initialize, #new_parameter, #new_request_builder, #new_response_handler, user_agent, user_agent_parameters
Constructor Details
This class inherits a constructor from ApiReference::BaseApi
Instance Method Details
#amend_event(event_id, body) ⇒ ApiResponse
This endpoint is used to amend a single usage event with a given
event_id. event_id refers to the
idempotency_key passed in during ingestion. The event will maintain its
existing event_id after the amendment.
This endpoint will mark the existing event as ignored, and Orb will only
use the new event passed in the body of
this request as the source of truth for that event_id. Note that a
single event can be amended any number of
times, so the same event can be overwritten in subsequent calls to this
endpoint. Only a single event with a given
event_id will be considered the source of truth at any given time.
This is a powerful and audit-safe mechanism to retroactively update a
single event in cases where you need to:
- update an event with new metadata as you iterate on your pricing model
- update an event based on the result of an external API call (e.g. call to a payment gateway succeeded or failed) This amendment API is always audit-safe. The process will still retain the original event, though it will be ignored for billing calculations. For auditing and data fidelity purposes, Orb never overwrites or permanently deletes ingested usage data.
Request validation
- The
timestampof the new event must match thetimestampof the existing event already ingested. As with ingestion, all timestamps must be sent in ISO8601 format with UTC timezone offset. - The
customer_idorexternal_customer_idof the new event must match thecustomer_idorexternal_customer_idof the existing event already ingested. Exactly one ofcustomer_idandexternal_customer_idshould be specified, and similar to ingestion, the ID must identify a Customer resource within Orb. Unlike ingestion, for event amendment, we strictly enforce that the Customer must be in the Orb system, even during the initial integration period. We do not allow updating theCustomeran event is associated with. - Orb does not accept an
idempotency_keywith the event in this endpoint, since this request is by design idempotent. On retryable errors, you should retry the request and assume the amendment operation has not succeeded until receipt of a 2xx. - The event's
timestampmust fall within the customer's current subscription's billing period, or within the grace period of the customer's current subscription's previous billing period. - By default, no more than 100 events can be amended for a single customer in a 100 day period. For higher volume updates, consider using the event backfill endpoint. here
443 444 445 446 447 448 449 450 451 452 453 454 455 456 457 458 459 460 461 462 463 464 465 466 467 468 469 470 471 472 473 474 475 476 477 478 479 480 481 482 483 484 |
# File 'lib/api_reference/apis/event_api.rb', line 443 def amend_event(event_id, body) @api_call .request(new_request_builder(HttpMethodEnum::PUT, '/events/{event_id}', Server::DEFAULT) .template_param(new_parameter(event_id, key: 'event_id') .is_required(true) .should_encode(true)) .header_param(new_parameter('application/json', key: 'Content-Type')) .body_param(new_parameter(body) .is_required(true)) .header_param(new_parameter('application/json', key: 'accept')) .body_serializer(proc do |param| param.to_json unless param.nil? end) .auth(Single.new('APIKeyAuth'))) .response(new_response_handler .deserializer(APIHelper.method(:custom_type_deserializer)) .deserialize_into(AmendEventResult.method(:from_hash)) .is_api_response(true) .local_error('400', 'Bad Request', APIException) .local_error('401', 'Unauthorized', AuthorizationErrorException) .local_error('404', 'Not Found', APIException) .local_error('409', 'Conflict', IdempotencyRequestMismatchException) .local_error('413', 'Content Too Large', APIException) .local_error('429', 'Too Many Requests', TooManyRequestsException) .local_error('500', 'Internal Server Error', ServerErrorException)) .execute end |
#close_backfill(backfill_id) ⇒ ApiResponse
Closing a backfill makes the updated usage visible in Orb. Upon closing a
backfill, Orb will asynchronously reflect
the updated usage in invoice amounts and usage graphs. Once all of the
updates are complete, the backfill's status
will transition to reflected.
here
185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 |
# File 'lib/api_reference/apis/event_api.rb', line 185 def close_backfill(backfill_id) @api_call .request(new_request_builder(HttpMethodEnum::POST, '/events/backfills/{backfill_id}/close', Server::DEFAULT) .template_param(new_parameter(backfill_id, key: 'backfill_id') .is_required(true) .should_encode(true)) .header_param(new_parameter('application/json', key: 'accept')) .auth(Single.new('APIKeyAuth'))) .response(new_response_handler .deserializer(APIHelper.method(:custom_type_deserializer)) .deserialize_into(Backfill.method(:from_hash)) .is_api_response(true) .local_error('400', 'Bad Request', APIException) .local_error('401', 'Unauthorized', AuthorizationErrorException) .local_error('404', 'Not Found', APIException) .local_error('409', 'Conflict', IdempotencyRequestMismatchException) .local_error('413', 'Content Too Large', APIException) .local_error('429', 'Too Many Requests', TooManyRequestsException) .local_error('500', 'Internal Server Error', ServerErrorException)) .execute end |
#create_backfill(body) ⇒ ApiResponse
Creating the backfill enables adding or replacing past events, even those that are older than the ingestion grace period. Performing a backfill in Orb involves 3 steps:
- Create the backfill, specifying its parameters.
- Ingest usage events, referencing
the backfill (query parameter
backfill_id). - Close the
backfill, propagating the update in past usage throughout Orb.
Changes from a backfill are not reflected until the
backfill is closed, so you won’t need to worry about your customers seeing
partially updated usage data. Backfills are
also reversible, so you’ll be able to revert a backfill if you’ve made a
mistake.
This endpoint will return a
backfill object, which contains an
id. Thatidcan then be used as thebackfill_idquery parameter to the event ingestion endpoint to associate ingested events with this backfill. The effects (e.g. updated usage graphs) of this backfill will not take place until the backfill is closed. If thereplace_existing_eventsistrue, existing events in the backfill's timeframe will be replaced with the newly ingested events associated with the backfill. Iffalse, newly ingested events will be added to the existing events. If acustomer_idorexternal_customer_idis specified, the backfill will only affect events for that customer. If neither is specified, the backfill will affect all customers. Whenreplace_existing_eventsistrue, this indicates that existing events in the timeframe should no longer be counted towards invoiced usage. In this scenario, the parameterdeprecation_filtercan be optionally added which enables filtering using computed properties. The expressiveness of computed properties allows you to deprecate existing events based on both a period of time and specific property values. You may not have multiple backfills in a pending or pending_revert state with overlapping timeframes. here
96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 |
# File 'lib/api_reference/apis/event_api.rb', line 96 def create_backfill(body) @api_call .request(new_request_builder(HttpMethodEnum::POST, '/events/backfills', Server::DEFAULT) .header_param(new_parameter('application/json', key: 'Content-Type')) .body_param(new_parameter(body) .is_required(true)) .header_param(new_parameter('application/json', key: 'accept')) .body_serializer(proc do |param| param.to_json unless param.nil? end) .auth(Single.new('APIKeyAuth'))) .response(new_response_handler .deserializer(APIHelper.method(:custom_type_deserializer)) .deserialize_into(Backfill.method(:from_hash)) .is_api_response(true) .local_error('400', 'Bad Request', APIException) .local_error('401', 'Unauthorized', AuthorizationErrorException) .local_error('404', 'Not Found', APIException) .local_error('409', 'Conflict', IdempotencyRequestMismatchException) .local_error('413', 'Content Too Large', APIException) .local_error('429', 'Too Many Requests', TooManyRequestsException) .local_error('500', 'Internal Server Error', ServerErrorException)) .execute end |
#deprecate_event(event_id) ⇒ ApiResponse
This endpoint is used to deprecate a single usage event with a given
event_id. event_id refers to the
idempotency_key passed in during ingestion.
This endpoint will mark the existing event as ignored. Note that if you
attempt to re-ingest an event with the same
event_id as a deprecated event, Orb will return an error.
This is a powerful and audit-safe mechanism to retroactively deprecate a
single event in cases where you need to:
- no longer bill for an event that was improperly reported
- no longer bill for an event based on the result of an external API call (e.g. call to a payment gateway failed and the user should not be billed) If you want to only change specific properties of an event, but keep the event as part of the billing calculation, use the Amend event endpoint instead. This API is always audit-safe. The process will still retain the deprecated event, though it will be ignored for billing calculations. For auditing and data fidelity purposes, Orb never overwrites or permanently deletes ingested usage data.
Request validation
- Orb does not accept an
idempotency_keywith the event in this endpoint, since this request is by design idempotent. On retryable errors, you should retry the request and assume the deprecation operation has not succeeded until receipt of a 2xx. - The event's
timestampmust fall within the customer's current subscription's billing period, or within the grace period of the customer's current subscription's previous billing period. Orb does not allow deprecating events for billing periods that have already invoiced customers. - The
customer_idor theexternal_customer_idof the original event ingestion request must identify a Customer resource within Orb, even if this event was ingested during the initial integration period. We do not allow deprecating events for customers not in the Orb system. - By default, no more than 100 events can be deprecated for a single customer in a 100 day period. For higher volume updates, consider using the event backfill endpoint.
527 528 529 530 531 532 533 534 535 536 537 538 539 540 541 542 543 544 545 546 547 548 549 550 551 552 553 554 555 556 557 558 559 560 561 562 563 |
# File 'lib/api_reference/apis/event_api.rb', line 527 def deprecate_event(event_id) @api_call .request(new_request_builder(HttpMethodEnum::PUT, '/events/{event_id}/deprecate', Server::DEFAULT) .template_param(new_parameter(event_id, key: 'event_id') .is_required(true) .should_encode(true)) .header_param(new_parameter('application/json', key: 'accept')) .auth(Single.new('APIKeyAuth'))) .response(new_response_handler .deserializer(APIHelper.method(:custom_type_deserializer)) .deserialize_into(DeprecatedEventResult.method(:from_hash)) .is_api_response(true) .local_error('400', 'Bad Request', APIException) .local_error('401', 'Unauthorized', AuthorizationErrorException) .local_error('404', 'Not Found', APIException) .local_error('409', 'Conflict', IdempotencyRequestMismatchException) .local_error('413', 'Content Too Large', APIException) .local_error('429', 'Too Many Requests', TooManyRequestsException) .local_error('500', 'Internal Server Error', ServerErrorException)) .execute end |
#fetch_backfill(backfill_id) ⇒ ApiResponse
This endpoint is used to fetch a backfill given an identifier. here
139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 |
# File 'lib/api_reference/apis/event_api.rb', line 139 def fetch_backfill(backfill_id) @api_call .request(new_request_builder(HttpMethodEnum::GET, '/events/backfills/{backfill_id}', Server::DEFAULT) .template_param(new_parameter(backfill_id, key: 'backfill_id') .is_required(true) .should_encode(true)) .header_param(new_parameter('application/json', key: 'accept')) .auth(Single.new('APIKeyAuth'))) .response(new_response_handler .deserializer(APIHelper.method(:custom_type_deserializer)) .deserialize_into(Backfill.method(:from_hash)) .is_api_response(true) .local_error('400', 'Bad Request', APIException) .local_error('401', 'Unauthorized', AuthorizationErrorException) .local_error('404', 'Not Found', APIException) .local_error('409', 'Conflict', IdempotencyRequestMismatchException) .local_error('413', 'Content Too Large', APIException) .local_error('429', 'Too Many Requests', TooManyRequestsException) .local_error('500', 'Internal Server Error', ServerErrorException)) .execute end |
#get_event_volume(timeframe_start, limit: 20, cursor: nil, timeframe_end: nil) ⇒ ApiResponse
This endpoint returns the event volume for an account in a paginated list format. The event volume is aggregated by the hour and the timestamp field is used to determine which hour an event is associated with. Note, this means that late-arriving events increment the volume count for the hour window the timestamp is in, not the latest hour window. Each item in the response contains the count of events aggregated by the hour where the start and end time are hour-aligned and in UTC. When a specific timestamp is passed in for either start or end time, the response includes the hours the timestamp falls in. description here here
347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 |
# File 'lib/api_reference/apis/event_api.rb', line 347 def get_event_volume(timeframe_start, limit: 20, cursor: nil, timeframe_end: nil) @api_call .request(new_request_builder(HttpMethodEnum::GET, '/events/volume', Server::DEFAULT) .query_param(new_parameter(timeframe_start, key: 'timeframe_start') .is_required(true)) .query_param(new_parameter(limit, key: 'limit')) .query_param(new_parameter(cursor, key: 'cursor')) .query_param(new_parameter(timeframe_end, key: 'timeframe_end')) .header_param(new_parameter('application/json', key: 'accept')) .auth(Single.new('APIKeyAuth'))) .response(new_response_handler .deserializer(APIHelper.method(:custom_type_deserializer)) .deserialize_into(EventVolumes.method(:from_hash)) .is_api_response(true) .local_error('400', 'Bad Request', APIException) .local_error('401', 'Unauthorized', AuthorizationErrorException) .local_error('404', 'Not Found', APIException) .local_error('409', 'Conflict', IdempotencyRequestMismatchException) .local_error('413', 'Content Too Large', APIException) .local_error('429', 'Too Many Requests', TooManyRequestsException) .local_error('500', 'Internal Server Error', ServerErrorException)) .execute end |
#ingest(body, debug: false, backfill_id: nil) ⇒ ApiResponse
Orb's event ingestion model and API is designed around two core principles:
- 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.
- 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:
{
// 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_keyare unique strings that you generated with V4 UUIDs, but only require that they uniquely identify an event (i.e. don’t collide). - The
timestampfield 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 range12-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_mscan 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_idandexternal_customer_idshould be specified. - If the
customer_idis specified, the customer in Orb must exist. - If the
external_customer_idis specified, the customer in Orb does not need to exist. Events will be attributed to any future customers with theexternal_customer_idon subscription creation. timestampmust 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
4xxHTTP 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
5xxHTTP 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
{
"validation_failed": []
}
here here
733 734 735 736 737 738 739 740 741 742 743 744 745 746 747 748 749 750 751 752 753 754 755 756 757 758 759 760 761 762 763 764 765 766 767 768 769 770 771 772 773 774 |
# File 'lib/api_reference/apis/event_api.rb', line 733 def ingest(body, debug: false, backfill_id: nil) @api_call .request(new_request_builder(HttpMethodEnum::POST, '/ingest', Server::DEFAULT) .header_param(new_parameter('application/json', key: 'Content-Type')) .body_param(new_parameter(body) .is_required(true)) .query_param(new_parameter(debug, key: 'debug')) .query_param(new_parameter(backfill_id, key: 'backfill_id')) .header_param(new_parameter('application/json', key: 'accept')) .body_serializer(proc do |param| param.to_json unless param.nil? end) .auth(Single.new('APIKeyAuth'))) .response(new_response_handler .deserializer(APIHelper.method(:custom_type_deserializer)) .deserialize_into(IngestionResponse.method(:from_hash)) .is_api_response(true) .local_error('400', 'Bad Request', APIException) .local_error('401', 'Unauthorized', AuthorizationErrorException) .local_error('404', 'Not Found', APIException) .local_error('409', 'Conflict', IdempotencyRequestMismatchException) .local_error('413', 'Content Too Large', APIException) .local_error('429', 'Too Many Requests', TooManyRequestsException) .local_error('500', 'Internal Server Error', ServerErrorException)) .execute end |
#list_backfills(limit: 20, cursor: nil) ⇒ ApiResponse
This endpoint returns a list of all backfills in a list format.
The list of backfills is ordered starting from the most recently created
backfill. The response also includes
pagination_metadata, which lets the caller
retrieve the next page of results if they
exist.
18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 |
# File 'lib/api_reference/apis/event_api.rb', line 18 def list_backfills(limit: 20, cursor: nil) @api_call .request(new_request_builder(HttpMethodEnum::GET, '/events/backfills', Server::DEFAULT) .query_param(new_parameter(limit, key: 'limit')) .query_param(new_parameter(cursor, key: 'cursor')) .header_param(new_parameter('application/json', key: 'accept')) .auth(Single.new('APIKeyAuth'))) .response(new_response_handler .deserializer(APIHelper.method(:custom_type_deserializer)) .deserialize_into(Backfills.method(:from_hash)) .is_api_response(true) .local_error('400', 'Bad Request', APIException) .local_error('401', 'Unauthorized', AuthorizationErrorException) .local_error('404', 'Not Found', APIException) .local_error('409', 'Conflict', IdempotencyRequestMismatchException) .local_error('413', 'Content Too Large', APIException) .local_error('429', 'Too Many Requests', TooManyRequestsException) .local_error('500', 'Internal Server Error', ServerErrorException)) .execute end |
#revert_backfill(backfill_id) ⇒ ApiResponse
Reverting a backfill undoes all the effects of closing the backfill. If
the backfill is reflected, the status will
transition to pending_revert while the effects of the backfill are
undone. Once all effects are undone, the
backfill will transition to reverted.
If a backfill is reverted before its closed, no usage will be updated as a
result of the backfill and it will
immediately transition to reverted.
here
234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 |
# File 'lib/api_reference/apis/event_api.rb', line 234 def revert_backfill(backfill_id) @api_call .request(new_request_builder(HttpMethodEnum::POST, '/events/backfills/{backfill_id}/revert', Server::DEFAULT) .template_param(new_parameter(backfill_id, key: 'backfill_id') .is_required(true) .should_encode(true)) .header_param(new_parameter('application/json', key: 'accept')) .auth(Single.new('APIKeyAuth'))) .response(new_response_handler .deserializer(APIHelper.method(:custom_type_deserializer)) .deserialize_into(Backfill.method(:from_hash)) .is_api_response(true) .local_error('400', 'Bad Request', APIException) .local_error('401', 'Unauthorized', AuthorizationErrorException) .local_error('404', 'Not Found', APIException) .local_error('409', 'Conflict', IdempotencyRequestMismatchException) .local_error('413', 'Content Too Large', APIException) .local_error('429', 'Too Many Requests', TooManyRequestsException) .local_error('500', 'Internal Server Error', ServerErrorException)) .execute end |
#search_events(body) ⇒ ApiResponse
This endpoint returns a filtered set of events for an account in a
paginated list format.
Note that this is a POST endpoint rather than a GET endpoint because
it employs a JSON body for search criteria
rather than query parameters, allowing for a more flexible search syntax.
Note that a search criteria must be specified. Currently, Orb supports
the following criteria:
event_ids: This is an explicit array of IDs to filter by. Note that an event's ID is theidempotency_keythat was originally used for ingestion. By default, Orb will not throw a404if no events matched, Orb will return an empty array fordatainstead. description here
287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 |
# File 'lib/api_reference/apis/event_api.rb', line 287 def search_events(body) @api_call .request(new_request_builder(HttpMethodEnum::POST, '/events/search', Server::DEFAULT) .header_param(new_parameter('application/json', key: 'Content-Type')) .body_param(new_parameter(body) .is_required(true)) .header_param(new_parameter('application/json', key: 'accept')) .body_serializer(proc do |param| param.to_json unless param.nil? end) .auth(Single.new('APIKeyAuth'))) .response(new_response_handler .deserializer(APIHelper.method(:custom_type_deserializer)) .deserialize_into(Events.method(:from_hash)) .is_api_response(true) .local_error('400', 'Bad Request', APIException) .local_error('401', 'Unauthorized', AuthorizationErrorException) .local_error('404', 'Not Found', APIException) .local_error('409', 'Conflict', IdempotencyRequestMismatchException) .local_error('413', 'Content Too Large', APIException) .local_error('429', 'Too Many Requests', TooManyRequestsException) .local_error('500', 'Internal Server Error', ServerErrorException)) .execute end |