/*
* Zernio API
*
* API reference for Zernio. Authenticate with a Bearer API key. Base URL: https://zernio.com/api Versioning and deprecation: all endpoints are versioned in the URL path (current version: /v1). Breaking changes only ship in a new path version; existing versions keep working. Deprecated operations are marked 'deprecated: true' in this spec and announced in the changelog (https://zernio.com/changelog) before removal. Errors: every 4xx/5xx response is application/json with a machine-readable 'code' and a human-readable 'error' message (see the ErrorResponse schema). Request ids: responses carry an X-Request-Id header with the id we log the request under. Quote it when reporting a problem. A valid x-request-id you send is reused as that id.
*
* The version of the OpenAPI document: 1.104.0
* Contact: support@zernio.com
* Generated by: https://openapi-generator.tech
*/
use crate::models;
use serde::{Deserialize, Serialize};
/// WebhookPayloadAnalyticsSynced : Webhook payload for `analytics.synced`. Fired once per connected account each time its analytics sync cycle completes successfully. Poll-driven (roughly hourly per account), not real-time, and never fired for a skipped or failed cycle. A TRIGGER, not a transport: it deliberately carries no metrics and no cursor. When it arrives, call `GET /v1/analytics/delta` with YOUR OWN last `nextCursor` to read what changed, across every account, in one paginated stream. The absent cursor is deliberate. The feed's ordering position is assigned inside the analytics store when the row is materialized, which normally has not happened yet at the moment this event fires, so a cursor minted here could sit ahead of the very rows the event announces and make you skip them. Your own `nextCursor` is always in the feed's own ordering and can never do that. Because of that same lag, a delta read issued the instant this event lands can legitimately come back empty. That is not \"nothing changed\": poll again with the same cursor you last used rather than treating the account as done. Subscribe to this event on a DEDICATED webhook endpoint. It is high volume (roughly one delivery per connected account per hour) and a subscription's consecutive-failure count is shared across all of its events, so an outage while this event is flowing can suppress the low-volume publishing events that share the same subscription.
#[derive(Clone, Default, Debug, PartialEq, Serialize, Deserialize)]
pub struct WebhookPayloadAnalyticsSynced {
/// Stable webhook event ID
#[serde(rename = "id")]
pub id: String,
#[serde(rename = "event")]
pub event: Event,
#[serde(rename = "account")]
pub account: Box<models::WebhookPayloadAnalyticsSyncedAccount>,
#[serde(rename = "sync")]
pub sync: Box<models::WebhookPayloadAnalyticsSyncedSync>,
/// UTC time at which Zernio generated this event (set once when the event payload is built, before delivery is queued).
#[serde(rename = "timestamp")]
pub timestamp: String,
}
impl WebhookPayloadAnalyticsSynced {
/// Webhook payload for `analytics.synced`. Fired once per connected account each time its analytics sync cycle completes successfully. Poll-driven (roughly hourly per account), not real-time, and never fired for a skipped or failed cycle. A TRIGGER, not a transport: it deliberately carries no metrics and no cursor. When it arrives, call `GET /v1/analytics/delta` with YOUR OWN last `nextCursor` to read what changed, across every account, in one paginated stream. The absent cursor is deliberate. The feed's ordering position is assigned inside the analytics store when the row is materialized, which normally has not happened yet at the moment this event fires, so a cursor minted here could sit ahead of the very rows the event announces and make you skip them. Your own `nextCursor` is always in the feed's own ordering and can never do that. Because of that same lag, a delta read issued the instant this event lands can legitimately come back empty. That is not \"nothing changed\": poll again with the same cursor you last used rather than treating the account as done. Subscribe to this event on a DEDICATED webhook endpoint. It is high volume (roughly one delivery per connected account per hour) and a subscription's consecutive-failure count is shared across all of its events, so an outage while this event is flowing can suppress the low-volume publishing events that share the same subscription.
pub fn new(
id: String,
event: Event,
account: models::WebhookPayloadAnalyticsSyncedAccount,
sync: models::WebhookPayloadAnalyticsSyncedSync,
timestamp: String,
) -> WebhookPayloadAnalyticsSynced {
WebhookPayloadAnalyticsSynced {
id,
event,
account: Box::new(account),
sync: Box::new(sync),
timestamp,
}
}
}
///
#[derive(Clone, Copy, Debug, Eq, PartialEq, Ord, PartialOrd, Hash, Serialize, Deserialize)]
pub enum Event {
#[serde(rename = "analytics.synced")]
AnalyticsSynced,
}
impl Default for Event {
fn default() -> Event {
Self::AnalyticsSynced
}
}