[AlertOps] Assign an alert. THIS REACHES A HUMAN NOW: it pages on-call staff, notifies subscribers, or sends email / SMS / Slack messages. Do not call it to test behavior. Request body fields (AlertAssignRequest): user (string). Assignment notifies the new owner, so it reaches a person even though nothing about the alert is resolved. alertops_bulk_assign_alerts does the same for many alerts at once.

[AlertOps] Assign alerts in bulk. THIS REACHES A HUMAN NOW: it pages on-call staff, notifies subscribers, or sends email / SMS / Slack messages. Do not call it to test behavior. Request body fields (AlertAssignBulkRequest): user (string); alerts (array<integer>). Every alert in the request notifies its new owner, so one call can page many people. Assign a single alert with alertops_assign_alert.

[AlertOps] Close alerts in bulk. This SUPPRESSES alerting. The failure mode is a monitoring blind spot: a real incident stops paging anyone. Request body fields (AlertCloseBulkRequest): user (string); resolution (string); alerts (array<integer>). Closing stops escalation on every alert in the request at once, and there is no undo - check the list with alertops_list_alerts first. Close a single alert with alertops_close_alert.

[AlertOps] Close an alert. This SUPPRESSES alerting. The failure mode is a monitoring blind spot: a real incident stops paging anyone. Request body fields (AlertCloseRequest): user (string); resolution (string). Closing stops the escalation, so anybody it was still going to page will not be. alertops_bulk_close_alerts does the same for many alerts at once.

[AlertOps] Raise a new alert, which AlertOps immediately routes down an escalation policy. THIS REACHES A HUMAN NOW: it pages on-call staff, notifies subscribers, or sends email / SMS / Slack messages. Do not call it to test behavior. Request body fields (AlertCreateRequest): escalation_policy (string); response_play (string); priority (string); source (string); source_name (string); source_id (string); source_url (string); topic (string); subject (string); description (string); bridge (string); is_incident (boolean, required); alert_tags (AlertCorrelationFields); alert_fields (array<AlertFieldItemUpdate>); recipients (array<AlertRecipientItem>); attachments (array<AlertFile>); technical_services (array<integer>). To record an incident or maintenance event that pages nobody, use alertops_create_incident instead.

[AlertOps] Add a message to an alert (reply). THIS REACHES A HUMAN NOW: it pages on-call staff, notifies subscribers, or sends email / SMS / Slack messages. Do not call it to test behavior. Request body fields (AlertMessageRequest): message_text (string); escalation_policy_id (integer); response_play_id (integer); recipients (array<AlertRecipientItem>). A message is delivered to the alert's recipients over their contact methods. To record something for other operators only, use alertops_create_alert_note, which notifies nobody.

[AlertOps] Add a note to an alert. Request body fields (AlertNoteRequest): note (string). A note is internal: unlike alertops_create_alert_message it notifies nobody.

[AlertOps] Add action to an alert. This FIRES a live dispatch to an external system immediately. Request body fields (AlertActionRequest): action (string). The action runs against the outbound integration wired to this alert. List the ones already run with alertops_list_alert_outbound_actions.

[AlertOps] Create alert postmortem. Request body fields (AlertPostmortemUpdate): name (string); status (string); impact_start (string); impact_end (string); notify_subscribers (boolean, required); postmortem_fields (array<AlertPostmortemFieldItemUpdate>).

[AlertOps] Add recipients to an alert. THIS REACHES A HUMAN NOW: it pages on-call staff, notifies subscribers, or sends email / SMS / Slack messages. Do not call it to test behavior. Request body fields (AlertRecipientsRequest): cancel_notifications (boolean, required); recipients (array<AlertCreateRecipient>); escalation_policy (string); response_play (string). The added recipients are paged over their own contact methods as soon as they are attached. List who is already on the alert with alertops_list_alert_recipients.

[AlertOps] Get one alert, with its status, priority, owner, source integration, escalation policy and recipients. Its id is what alertops_list_alert_messages, alertops_list_alert_notes, alertops_get_alert_timeline and every write in this family take.

[AlertOps] Get an alert's timeline - the ordered record of every escalation step, notification and human action. This is the read to use when reconstructing who was paged and when.

[AlertOps] List alerts - the individual pages AlertOps has raised, each carrying its status, priority, owner, source integration and escalation policy. Start here: every other tool in this family takes the alert id this returns. IMPORTANT: with no date window this returns ONLY TODAY'S alerts - AlertOps defaults createdFrom and createdTo to today's date, so an empty result does NOT mean there are no alerts. Set createdFrom and createdTo (format yyyy-MM-dd) to search further back. A window wider than 6 months is REJECTED, not truncated. The same applies to closedFrom and closedTo. Paginated by CURSOR: limit defaults to 10 and is capped at 100 (StackJack clamps out-of-range values). Pass the metadata.next value from the previous response back as next to page forward; treat it as opaque and do not do arithmetic on it.

[AlertOps] Snooze an alert. This SUPPRESSES alerting. The failure mode is a monitoring blind spot: a real incident stops paging anyone. Request body fields (AlertSnoozeRequest): snooze_hours (string). While an alert is snoozed nobody is paged for it, so a real incident can go unnoticed for the whole snooze window. alertops_update_alert_snooze changes an existing snooze.

[AlertOps] Update an alert. Request body fields (AlertUpdateRequest): source (string); source_name (string); source_id (string); source_url (string); status (string); owner (string); resolution (string); alert_tags (AlertCorrelationFields); alert_fields (array<AlertFieldItemUpdate>). To change status use the dedicated verbs - alertops_close_alert, alertops_assign_alert, alertops_snooze_alert - rather than writing status through this body.

[AlertOps] Update alert fields. AlertOps publishes no schema for this request body. Send the object shape documented in the AlertOps API reference for this endpoint. These are the custom fields defined on the alert, not its status or priority; change those with alertops_update_alert or the dedicated status verbs.

[AlertOps] Update an alert note. Request body fields (AlertNoteRequest): note (string). Notes are internal and notify nobody, so editing one pages no-one either.

[AlertOps] Update alert postmortem. Request body fields (AlertPostmortemUpdate): name (string); status (string); impact_start (string); impact_end (string); notify_subscribers (boolean, required); postmortem_fields (array<AlertPostmortemFieldItemUpdate>).

[AlertOps] Snooze an alert. This SUPPRESSES alerting. The failure mode is a monitoring blind spot: a real incident stops paging anyone. Request body fields (AlertSnoozeRequest): snooze_hours (string). Extending a snooze extends the window in which nobody is paged. alertops_snooze_alert starts one.

[AlertOps] Create a bridge. Request body fields (BridgeItemBase): telephone_number (string); telephone_access_code (string); telephone_message_body (string); message_priority_type (string); name (string).

[AlertOps] Delete a bridge. This DELETES data in AlertOps and cannot be undone from StackJack. Alerts and policies still pointing at this bridge lose their dial-in, so responders are paged with nowhere to join.

[AlertOps] Update a bridge. Request body fields (BridgeItemBase): telephone_number (string); telephone_access_code (string); telephone_message_body (string); message_priority_type (string); name (string).

[AlertOps] Create an incident / maintenance. THIS REACHES A HUMAN NOW: it pages on-call staff, notifies subscribers, or sends email / SMS / Slack messages. Do not call it to test behavior. AlertOps publishes no schema for this body, only this example - transcribe its shape rather than parsing it: {"is_maintenance":true,"incident_state":"Investigating/ Identified/ Monitoring /Resolved","description":"This is incident/ maintenance decription","component_id":[123,456],"notify_subscribers":true,"email":"true (Only if notify_subscribers = true)","sms":"true (Only if notify_subscribers = true)","slack_dm":"false (Only if notify_subscribers = true and accounts enabled)","subject":"This is incident/ maintenance Subject","start_date":"2021-8-6","start_hour":10,"start_minute":30,"duration_minutes":50,"notify_hour_before":true,"notify_at_start":true,"notify_at_end":true} It can notify subscribers immediately: notify_subscribers together with email, sms or slack_dm sends to your status-page audience the moment this is called. Set notify_subscribers false to record the incident quietly.

[AlertOps] Create an incident postmortem. Request body fields (AlertPostmortemUpdate): name (string); status (string); impact_start (string); impact_end (string); notify_subscribers (boolean, required); postmortem_fields (array<AlertPostmortemFieldItemUpdate>). Additive and internal: writing a postmortem notifies nobody.

[AlertOps] Get an incident's postmortem. Its fields are the ones defined by alertops_list_postmortem_fields.

[AlertOps] List the notifications already sent for an incident - who was told, over which channel and when. Use this to check whether subscribers have been notified before sending another update.

[AlertOps] List incidents and maintenance events - the customer-facing status records, which are separate from the alerts that page on-call staff. Use alertops_list_alerts for those.

[AlertOps] Update an incident / maintenance. THIS REACHES A HUMAN NOW: it pages on-call staff, notifies subscribers, or sends email / SMS / Slack messages. Do not call it to test behavior. AlertOps publishes no schema for this body, only this example - transcribe its shape rather than parsing it: {"is_maintenance":true,"incident_state":"Investigating/ Identified/ Monitoring /Resolved","description":"This is incident/ maintenance decription","component_id":[123,456],"notify_subscribers":true,"email":"true (Only if notify_subscribers = true)","sms":"true (Only if notify_subscribers = true)","slack_dm":"false (Only if notify_subscribers = true and accounts enabled)","subject":"This is incident/ maintenance Subject","start_date":"2021-8-6","start_hour":10,"start_minute":30,"duration_minutes":50,"notify_hour_before":true,"notify_at_start":true,"notify_at_end":true} Changing incident_state, or setting notify_subscribers, sends an update to your status-page audience. Read the record back with alertops_get_incident first: the body carries the whole shape, including component_id.

[AlertOps] Update an incident postmortem. Request body fields (AlertPostmortemUpdate): name (string); status (string); impact_start (string); impact_end (string); notify_subscribers (boolean, required); postmortem_fields (array<AlertPostmortemFieldItemUpdate>).

[AlertOps] Create a maintenance window. This SUPPRESSES alerting. The failure mode is a monitoring blind spot: a real incident stops paging anyone. Request body fields (MaintenanceWindowBase): description (string); recurrence (string); integration (array<string>); start_date (string); end_date (string); start_time (string); end_time (string); sunday (boolean, required); monday (boolean, required); tuesday (boolean, required); wednesday (boolean, required); thursday (boolean, required); friday (boolean, required); saturday (boolean, required). For the duration of the window the covered sources stop paging anyone, so a real incident inside it goes unnoticed.

[AlertOps] Delete a maintenance window. This DELETES data in AlertOps and cannot be undone from StackJack. Alerting resumes for whatever the window was suppressing, which can page people at once for conditions that are already true.

[AlertOps] List maintenance windows - the planned periods in which AlertOps suppresses alerting. An open window is a deliberate monitoring blind spot, so check this before concluding that a quiet system is healthy.

[AlertOps] Update a maintenance window. This SUPPRESSES alerting. The failure mode is a monitoring blind spot: a real incident stops paging anyone. Request body fields (MaintenanceWindowBase): description (string); recurrence (string); integration (array<string>); start_date (string); end_date (string); start_time (string); end_time (string); sunday (boolean, required); monday (boolean, required); tuesday (boolean, required); wednesday (boolean, required); thursday (boolean, required); friday (boolean, required); saturday (boolean, required). Widening a window widens the period in which nothing pages; narrowing one can start alerting again immediately.

[AlertOps] Create a postmortem field. Request body fields (PostmortemField): field_name (string); required (boolean, required); active (boolean, required); sequence (integer, required); allow_ai_to_generate_content (boolean); prompt_to_generate_ai_content (string).

[AlertOps] Delete a postmortem field. This DELETES data in AlertOps and cannot be undone from StackJack. The field disappears from every postmortem form, and answers already recorded against it are no longer collected.

[AlertOps] Update a postmortem field. Request body fields (PostmortemField): field_name (string); required (boolean, required); active (boolean, required); sequence (integer, required); allow_ai_to_generate_content (boolean); prompt_to_generate_ai_content (string).

[AlertOps] Create a schedule. Request body fields (ScheduleRequest): group (string); schedule_name (string); schedule_type (string); continuous (boolean, required); time_zone (string); color (string); start_date (DateTimeX); end_date (DateTimeX); start_weekday (string); end_weekday (string); schedule_weekdays (WeekDays); rotate_frequency (string); rotate_daily (RotationFrequencyDaily); rotate_weekly (RotationFrequencyWeekly); rotate_monthly (RotationFrequencyMonthly); repeat_schedule (RepeatSchedule); include_all_users_in_group (boolean, required); users (array<ScheduleUser>); enabled (boolean, required); is_holiday_notify (boolean). Additive: the rotation takes effect for alerts routed to the group from now on.

[AlertOps] Delete a schedule. This DELETES data in AlertOps and cannot be undone from StackJack. The group loses that coverage window. Alerts arriving in it fall through to whatever the escalation policy does next, which may be nobody.

[AlertOps] Get who is on call right now for one or more groups. This is the read to use before any change to a schedule, a group's membership or an escalation policy, because it answers the only question that matters at page time: who would this reach.

[AlertOps] Update a schedule. Request body fields (ScheduleUpdateRequest): schedule_name (string); schedule_type (string); continuous (boolean, required); time_zone (string); color (string); start_date (DateTimeX); end_date (DateTimeX); start_weekday (string); end_weekday (string); schedule_weekdays (WeekDays); rotate_frequency (string); rotate_daily (RotationFrequencyDaily); rotate_weekly (RotationFrequencyWeekly); rotate_monthly (RotationFrequencyMonthly); repeat_schedule (RepeatSchedule); include_all_users_in_group (boolean, required); users (array<ScheduleUser>); enabled (boolean, required); is_holiday_notify (boolean). Changing a rotation changes who is paged tonight. Check the current answer with alertops_get_on_call_now before and after.

[AlertOps] Create an escalation policy. Additive: the new policy contacts nobody at call time and only reaches people once an alert is routed to it. member_roles, group_contact_notifications, workflows, outbound_integrations, outbound_actions and options can be supplied inline here, or added afterwards with alertops_create_policy_member_role, alertops_create_policy_workflow, alertops_create_policy_outbound_integration and alertops_create_policy_outbound_action. Request body fields (EscalationRuleCreateRequest): escalation_policy_name (string); description (string); priority (string); enabled (boolean); quick_launch (boolean); notify_using_centralized_settings (boolean); member_roles (array<MemberRole>); wait_time_before_notifying_next_group_in_min (integer); group_contact_notifications (GroupContactNotifications); workflows (array<EscalationPolicyWorkflow>); outbound_integrations (array<OutboundIntegrationService>); outbound_actions (array<OutboundAction>); options (Options).

[AlertOps] Add a contact method to a policy's group contact notifications. Additive: nothing is sent at call time, and it takes effect on the next alert routed to this policy. contact_method_name is a NAME AlertOps already defines for the group, not an id. Check what is already there with alertops_list_policy_group_contact_notify_contact_methods. Request body fields (GroupContactMethod): contact_method_name (string); wait_time_in_mins (integer, required); to_bcc_or_cc (string).

[AlertOps] Add a member role, or escalation tier, to a policy. Additive: nobody is contacted at call time. wait_time_between_members_in_mins, no_of_retries and retry_interval are what decide how hard this tier pages, and contact_methods decides over which channels. Request body fields (MemberRole): member_role_type (string); wait_time_between_members_in_mins (integer, required); role_wait_time_in_mins (integer); no_of_retries (integer, required); retry_interval (integer, required); contact_methods (array<MemberRoleContactMethod>).

[AlertOps] Add a contact method to a member role on a policy. Additive: nothing is sent at call time. sequence decides the order the channels fire in, and repeat, repeat_times and repeat_minutes decide whether the channel keeps paging until someone responds. Request body fields (MemberRoleContactMethod): contact_method_name (string); wait_time_in_mins (integer, required); repeat (boolean, required); repeat_times (integer, required); repeat_minutes (integer, required); to_bcc_or_cc (string); sequence (integer, required).

[AlertOps] Add an outbound action to a policy. This WIRES A LIVE EXTERNAL DISPATCH PATH onto the policy. It fires nothing at call time, so the blast radius is future alerts rather than this call: every alert routed through this policy from now on will fire it. Confirm the result with alertops_list_policy_outbound_actions. AlertOps publishes no schema for this request body. Send the object shape documented in the AlertOps API reference for this endpoint.

[AlertOps] Attach an outbound integration to a policy. This WIRES A LIVE EXTERNAL DISPATCH PATH onto the policy. It fires nothing at call time, so the blast radius is future alerts rather than this call: every alert routed through this policy from now on will be pushed to that external system. Confirm the result with alertops_list_policy_outbound_integrations. AlertOps publishes no schema for this request body. Send the object shape documented in the AlertOps API reference for this endpoint.

[AlertOps] Add a recipient to a policy. THIS REACHES A HUMAN NOW: it pages on-call staff, notifies subscribers, or sends email / SMS / Slack messages. Do not call it to test behavior. Beyond this call, every alert routed through this policy pages the recipient you add. Check who is already on it with alertops_list_policy_recipients first. AlertOps publishes no schema for this request body. Send the object shape documented in the AlertOps API reference for this endpoint.

[AlertOps] Attach a workflow to a policy. The workflow's own actions decide what happens when this policy runs, and those actions can post to a webhook or message users and groups, so read the workflow with alertops_get_workflow and alertops_list_workflow_actions before you attach it. AlertOps publishes no schema for this request body. Send the object shape documented in the AlertOps API reference for this endpoint.

[AlertOps] Delete an escalation policy. This DELETES data in AlertOps and cannot be undone from StackJack. Anything still routed to this policy stops reaching anyone, and that failure is silent - the alerts keep arriving and no human is paged. To take a policy out of service reversibly, use alertops_update_policy_status instead.

[AlertOps] Delete a contact method from a policy's group contact notifications. This DELETES data in AlertOps and cannot be undone from StackJack. The group stops being notified over that channel - a lost paging path rather than an error - so list the remaining ones with alertops_list_policy_group_contact_notify_contact_methods afterwards.

[AlertOps] Delete a member role from a policy. This DELETES data in AlertOps and cannot be undone from StackJack. Removing a tier removes the people it paged, so alerts that used to escalate to them no longer will.

[AlertOps] Delete a contact method from a member role on a policy. This DELETES data in AlertOps and cannot be undone from StackJack. That tier loses that paging channel, and if it was the tier's only one, the tier stops reaching anyone.

[AlertOps] Delete a policy's outbound actions. This DELETES data in AlertOps and cannot be undone from StackJack, and the external systems those actions dispatched to stop being told about this policy's alerts. List what is there with alertops_list_policy_outbound_actions first. AlertOps publishes no schema for this request body. Send the object shape documented in the AlertOps API reference for this endpoint.

[AlertOps] Delete a policy's outbound integrations. This DELETES data in AlertOps and cannot be undone from StackJack, and the external systems stop receiving this policy's alerts. To change one integration rather than remove them all, use alertops_update_policy_outbound_integration. AlertOps publishes no schema for this request body. Send the object shape documented in the AlertOps API reference for this endpoint.

[AlertOps] Delete a policy's recipients. This DELETES data in AlertOps and cannot be undone from StackJack. A policy with no recipients pages nobody: the alerts still arrive and still route, and no human is told. AlertOps publishes no schema for this request body. Send the object shape documented in the AlertOps API reference for this endpoint.

[AlertOps] Delete a policy's attached workflows. This DELETES data in AlertOps and cannot be undone from StackJack. The workflow definitions themselves survive - only the attachment to this policy is removed - but the automation they ran for this policy stops. AlertOps publishes no schema for this request body. Send the object shape documented in the AlertOps API reference for this endpoint.

[AlertOps] Get one escalation policy, including its member roles, group contact notifications, attached workflows, outbound integrations, outbound actions and options. The id parameter accepts the policy id OR the policy name; get either from alertops_list_policy.

[AlertOps] Get one contact method from a policy's group contact notifications. contactMethodName is a NAME, not an id, and the documented values contain spaces (for example Group Email); StackJack percent-encodes it for you. List the valid names with alertops_list_policy_group_contact_notify_contact_methods.

[AlertOps] Get one member role from a policy. memberRoleType is a NAME such as Primary or Manager, not an id; StackJack percent-encodes it for you. List the valid values with alertops_list_policy_member_roles.

[AlertOps] Get one contact method from a member role on a policy. Both memberRoleType (for example Primary) and contactMethodName (for example Primary Email) are NAMES containing spaces, not ids; StackJack percent-encodes both for you. List the valid values with alertops_list_policy_member_roles and alertops_list_policy_member_role_contact_methods.

[AlertOps] List escalation policies - the routing rules that decide which member roles, groups and recipients an alert reaches, in what order, with what wait times and retries. Start here: every other tool in this family takes the escalation policy id or name this returns. PAGED BY OFFSET, NOT BY CURSOR: limit is the page size (AlertOps defaults to 10 and caps it at 100; StackJack clamps out-of-range values) and offset is the row to start at, so the second page of a 50-row page is offset 50. This endpoint has no next or previous cursor - only alertops_list_alerts uses those.

[AlertOps] List the contact methods on a policy's group contact notifications - the channels AlertOps uses when it notifies a group rather than an individual, with the wait time before each one fires. Each row is addressed by contact method NAME, and the documented names contain spaces (for example Group Email, Group SMS, SLACK GROUP).

[AlertOps] List the contact methods on one member role of a policy - the channels that tier uses to reach a person, in sequence order, with their repeat settings. Both memberRoleType and each contact method are addressed by NAME rather than by id.

[AlertOps] List a policy's member roles - the escalation tiers (for example Primary, Manager) that decide who is paged first, who is paged next, how long AlertOps waits between members, and how many times it retries. member_role_type is a NAME, not an id.

[AlertOps] List the outbound actions wired onto a policy - the external dispatches it fires when an alert runs through it. Read this before and after alertops_create_policy_outbound_action or alertops_delete_policy_outbound_actions.

[AlertOps] List a policy's recipients - the users and groups an alert routed to this policy will reach. A policy with no recipients pages nobody, so an empty list here is the thing to look for when alerts arrive and no one responds.

[AlertOps] List the workflows attached to a policy. This returns the attachments; the workflow definitions themselves, with their conditions and actions, come from alertops_get_workflow.

[AlertOps] Update an escalation policy. This is a WHOLESALE-REPLACE write: the body carries the policy's whole shape, so any field you omit is lost. Read the policy back with alertops_get_policy first and send the member_roles, workflows, outbound_integrations and outbound_actions collections complete, or you silently drop the escalation tiers that page people. The body also carries enabled, so this tool can disable a policy without going through alertops_update_policy_status. Request body fields (EscalationRuleUpdateRequest): escalation_policy_name (string); description (string); priority (string); enabled (boolean); quick_launch (boolean); notify_using_centralized_settings (boolean); member_roles (array<MemberRole>); wait_time_before_notifying_next_group_in_min (integer); group_contact_notifications (GroupContactNotifications); workflows (array<EscalationPolicyWorkflow>); outbound_integrations (array<OutboundIntegrationService>); outbound_actions (array<OutboundAction>); options (Options).

[AlertOps] Update one contact method on a policy's group contact notifications. This changes the wait time before that channel fires and whether it is addressed TO, BCC or CC; nothing is sent at call time. Request body fields (GroupContactMethodUpdate): wait_time_in_mins (integer, required); to_bcc_or_cc (string).

[AlertOps] Update a member role on a policy. Raising the wait times or lowering the retry counts slows down or weakens how this tier pages; nothing is sent at call time. contact_methods is a collection on this body, so read the role back with alertops_get_policy_member_role and send it complete. Request body fields (MemberRoleUpdateRequest): wait_time_between_members_in_mins (integer, required); role_wait_time_in_mins (integer); no_of_retries (integer, required); retry_interval (integer, required); contact_methods (array<MemberRoleContactMethod>).

[AlertOps] Update one contact method on a member role of a policy. This is a WHOLESALE-REPLACE write: the body replaces the entire object, so any field you omit is lost. Read it back with alertops_get_policy_member_role_contact_method first and send every field - an omitted repeat or sequence rewrites how hard, and in what order, this channel pages a human. Request body fields (MemberRoleContactMethodUpdate): wait_time_in_mins (integer, required); repeat (boolean, required); repeat_times (integer, required); repeat_minutes (integer, required); to_bcc_or_cc (string); sequence (integer, required).

[AlertOps] Switch a policy between its own notification settings and the account's centralized ones. THIS REACHES A HUMAN NOW: flipping notify_using_centralized_settings changes the settings AlertOps pages with, so the very next alert routed here can notify a different set of people over different channels. Do not call it to test behavior. Request body fields (EscalationPolicyNotifyRequest): notify_using_centralized_settings (boolean, required).

[AlertOps] Update a policy's options. sla_in_hours and the acknowledgement, escalate and close flags change when AlertOps escalates an unacknowledged alert, and one_email_per_message and one_message_per_recipient change how many messages a person gets. Nothing is sent at call time. Read the current values with alertops_list_policy_options first. Request body fields (OptionsUpdateRequest): acknowledgement (OptionFlags); assignment (OptionFlags); escalate (OptionFlags); close (OptionFlags); notification_settings (NotificationSettingsDTO); escalation_policy_name_for_reply (string); sla_in_hours (number, required); message_text (string); include_alert_id_in_subject (boolean, required); one_email_per_message (boolean, required); one_message_per_recipient (boolean, required); sequence_group_first (boolean, required); alert_type (string).

[AlertOps] Update one outbound integration on a policy. This is a WHOLESALE-REPLACE write: actions replaces the whole action list, so an action you omit stops firing for this policy. Read the current list with alertops_list_policy_outbound_integrations first and send it back complete. interval_in_sec sets how often the integration re-fires; nothing is dispatched at call time. Get outboundIntegrationId from alertops_list_policy_outbound_integrations. Request body fields (OutboundIntegrationItemUpdate): interval_in_sec (integer, required); actions (array<OutboundIntegrationServiceAction>).

[AlertOps] Enable or disable an escalation policy. This SUPPRESSES alerting. The failure mode is a monitoring blind spot: with enabled false, a real incident routed here stops paging anyone and nothing reports an error. Disabling is the reversible alternative to alertops_delete_policy - re-enable with this same tool. Request body fields (ChangeEscalationPolicyStatusRequest): enabled (boolean, required).

[AlertOps] Create a user attribute. Request body fields (UserAttributeItemBase): attribute_name (string); user_attribute_data_type (string); reg_ex_validation (string); active (boolean, required); list_values (string); required (boolean, required); sequence (integer, required).

[AlertOps] Delete a user attribute. This DELETES data in AlertOps and cannot be undone from StackJack. The attribute disappears from every user record, and any dynamic recipient rule that selected people by it stops matching.

[AlertOps] List the user attribute definitions - the custom fields every user record is filled in against. Set one user's own values with alertops_update_user_attribute_values.

[AlertOps] Update a user attribute. Request body fields (UserAttributeItemBase): attribute_name (string); user_attribute_data_type (string); reg_ex_validation (string); active (boolean, required); list_values (string); required (boolean, required); sequence (integer, required).

[AlertOps] Create a user. This creates an identity or replaces a privilege-bearing object wholesale, so it can widen access. AlertOps publishes no schema for this body, only this example - transcribe its shape rather than parsing it: {"user_name":"string","first_name":"string","last_name":"string","locale":"string","time_zone":"string","type":"string","external_id":"string","contact_methods":[{"contact_method_name":"string","email":{"email_address":"string"},"phone":{"country_code":"string","phone_number":"string","extension":"string"},"sms":{"country_code":"string","phone_number":"string"},"gateway":{"provider":"string","address":"string"},"slack_dm":{"member_id":"string"},"wait_time_in_mins":0,"repeat":true,"repeat_times":0,"repeat_minutes":0,"notification_time24x7":true,"notification_times":[{"notification_time_id":0,"name":"string","sunday":true,"monday":true,"tuesday":true,"wednesday":true,"thursday":true,"friday":true,"saturday":true,"start_hour":0,"start_minute":0,"end_hour":0,"end_minute":0}],"enabled":true,"sequence":0}],"roles":["string"]} This creates a login-bearing identity, so it widens who can reach the account, not only who gets paged.

[AlertOps] Create a user's contact method. AlertOps publishes no schema for this body, only this example - transcribe its shape rather than parsing it: {"contact_method_name":"Phone-Official","email":null,"phone":{"country_code":"1","phone_number":"1234567890","extension":},"sms":null,"push_notification":null,"wait_time_in_mins":0,"repeat":false,"repeat_times":0,"repeat_minutes":0,"notification_time24x7":true,"notification_times":[{"notification_time_id":0,"name":,"sunday":false,"monday":true,"tuesday":true,"wednesday":true,"thursday":true,"friday":true,"saturday":false,"start_hour":9,"start_minute":0,"end_hour":18,"end_minute":0},{"notification_time_id":0,"name":"","sunday":false,"monday":true,"tuesday":true,"wednesday":true,"thursday":true,"friday":true,"saturday":false,"start_hour":8,"start_minute":0,"end_hour":18,"end_minute":0}],"enabled":false,"sequence":1} Additive: the channel is used on the next alert that pages this person, and nothing is sent at call time.

[AlertOps] Create a user's contact method notification times. Request body fields (NotificationTime): name (string); sunday (boolean, required); monday (boolean, required); tuesday (boolean, required); wednesday (boolean, required); thursday (boolean, required); friday (boolean, required); saturday (boolean, required); start_hour (integer, required); start_minute (integer, required); end_hour (integer, required); end_minute (integer, required). Outside the times you set this channel is not used, so a narrow window is a paging gap rather than an error.

[AlertOps] Create a user's out of office. This SUPPRESSES alerting. The failure mode is a monitoring blind spot: a real incident stops paging anyone. Request body fields (UserOOFRequest): start_date (DateTimeX); end_date (DateTimeX); all_groups (boolean, required); covering_users (array<CoverUserXRequest>). For the period you set this person is skipped during escalation, so a tier where they are the only member pages nobody.

[AlertOps] Delete a user. This DELETES data in AlertOps and cannot be undone from StackJack. Every escalation policy, group and schedule that pages this person stops reaching them, and where they were the only member of a tier that tier now pages nobody. To make someone temporarily unreachable, use alertops_create_user_out_of_office instead.

[AlertOps] Delete a user's contact method. This DELETES data in AlertOps and cannot be undone from StackJack. This person stops being reachable over that channel. If it was their only one, they can no longer be paged at all.

[AlertOps] Delete a user's contact method notification times. This DELETES data in AlertOps and cannot be undone from StackJack. Removing a window changes when this channel may be used, which can leave hours in which the person cannot be reached on it.

[AlertOps] Delete a user's out of office. This DELETES data in AlertOps and cannot be undone from StackJack. The person becomes reachable again for that period.

[AlertOps] List one user's attribute values. The fields available are defined by alertops_list_user_attribute_definitions.

[AlertOps] List a user's contact methods - the channels AlertOps pages them over, in the order it tries them. Each row is addressed by contact method NAME, not by id.

[AlertOps] List the groups a user belongs to. This is the fastest way to see what would page this person, because escalation policies route to groups rather than to individuals.

[AlertOps] List users - the people AlertOps can page, each with the roles and contact methods that decide how they are reached. Start here: every other tool in this family takes the user id this returns. Paginated by OFFSET, NOT by cursor: limit is the page size (AlertOps defaults to 10 and caps it at 100; StackJack clamps out-of-range values) and offset is the row to start at, so the page after a 50-row page is offset 50. This endpoint returns no next or previous cursor - only alertops_list_alerts uses those.

[AlertOps] Update a user. This creates an identity or replaces a privilege-bearing object wholesale, so it can widen access. AlertOps publishes no schema for this body, only this example - transcribe its shape rather than parsing it: {"user_name":"string","first_name":"string","last_name":"string","locale":"string","time_zone":"string","external_id":"string","contact_methods":[{"contact_method_name":"string","email":{"email_address":"string"},"phone":{"country_code":"string","phone_number":"string","extension":"string"},"sms":{"country_code":"string","phone_number":"string"},"gateway":{"provider":"string","address":"string"},"push_notification":{"platform":"string"},"slack_dm":{"member_id":"string"},"wait_time_in_mins":0,"repeat":true,"repeat_times":0,"repeat_minutes":0,"notification_time24x7":true,"notification_times":[{"notification_time_id":0,"name":"string","sunday":true,"monday":true,"tuesday":true,"wednesday":true,"thursday":true,"friday":true,"saturday":true,"start_hour":0,"start_minute":0,"end_hour":0,"end_minute":0}],"enabled":true,"sequence":0}],"roles":["string"]} Read the user back with alertops_get_user first and send the body complete: an omitted collection can silently strip roles or contact methods, which changes both their access and whether they can be paged.

[AlertOps] Update a user's attributes. AlertOps publishes no schema for this request body. Send the object shape documented in the AlertOps API reference for this endpoint.

[AlertOps] Update a user's contact method. This is a WHOLESALE-REPLACE write: the body replaces the entire object, so any field you omit is lost. Read the object first and send it back complete. AlertOps publishes no schema for this body, only this example - transcribe its shape rather than parsing it: {"email":null,"phone":{"country_code":"1","phone_number":"1234567890","extension":""},"sms":null,"push_notification":null,"wait_time_in_mins":0,"repeat":false,"repeat_times":0,"repeat_minutes":0,"notification_time24x7":true,"notification_times":[{"notification_time_id":10,"name":"Notification Schedule 1","sunday":false,"monday":true,"tuesday":true,"wednesday":true,"thursday":true,"friday":true,"saturday":false,"start_hour":9,"start_minute":0,"end_hour":18,"end_minute":0},{"notification_time_id":20,"name":"Notification Schedule 2","sunday":false,"monday":true,"tuesday":true,"wednesday":true,"thursday":true,"friday":true,"saturday":false,"start_hour":8,"start_minute":0,"end_hour":18,"end_minute":0}],"enabled":false,"sequence":1}

[AlertOps] Update a user's contact method notification times. This is a WHOLESALE-REPLACE write: the body replaces the entire object, so any field you omit is lost. Read the object first and send it back complete. Request body fields (NotificationTime): name (string); sunday (boolean, required); monday (boolean, required); tuesday (boolean, required); wednesday (boolean, required); thursday (boolean, required); friday (boolean, required); saturday (boolean, required); start_hour (integer, required); start_minute (integer, required); end_hour (integer, required); end_minute (integer, required).

[AlertOps] Update a user's out of office. This SUPPRESSES alerting. The failure mode is a monitoring blind spot: a real incident stops paging anyone. Request body fields (UserOOFRequest): start_date (DateTimeX); end_date (DateTimeX); all_groups (boolean, required); covering_users (array<CoverUserXRequest>). Widening the period widens the time this person is skipped during escalation.

[AlertOps] Create a group. AlertOps publishes no schema for this body, only this example - transcribe its shape rather than parsing it: {"group_name":"Group Name Sample 1","dynamic":false,"description":["TEST","test1"],"members":[{"member_type":"User","member":"testuser1","sequence":1,"roles":["Primary","Manager"]},{"member_type":"User","member":"testuser2","sequence":2,"roles":["Primary","Manager"]},{"member_type":"Group","member":"Existing Group Name","sequence":3,"roles":null}],"contact_methods":[{"email_address":"someone@somedomain.com","contact_method_name":"Primary Email","enabled":false,"sequence":1},{"country_code":"1","phone_number":"1234567890","extension":"2345","contact_method_name":"Primary Phone","enabled":false,"sequence":2},{"email_address":"someone@somedomain.com","contact_method_name":"Pager","enabled":false,"sequence":3},{"country_code":"1","phone_number":"1234567890","contact_method_name":"Group SMS","enabled":false,"sequence":4},{"url":"https://somedoamin.com","get_alert_update":false,"contact_method_name":"SLACK GROUP","enabled":true,"sequence":5}],"topics":["Valid Topic Name1","Valid Topic Name2"],"attributes":[{"attribute_name":"Attribute Name","attribute_value":"attribute value"}]} Additive: the new group pages nobody until an escalation policy or an integration routes an alert to it.

[AlertOps] Create a group's contact method. AlertOps publishes no schema for this body, only this example - transcribe its shape rather than parsing it: {"country_code":"1","phone_number":"1234567890","extension":"2345","contact_method_name":"Primary Phone","enabled":false,"sequence":1} Additive: the channel is used on the next alert routed to this group, and nothing is sent at call time.

[AlertOps] Add members to a group. AlertOps publishes no schema for this request body. Send the object shape documented in the AlertOps API reference for this endpoint. Additive: the added members are paged on the next alert routed to this group, not at call time.

[AlertOps] Add topics to a group. AlertOps publishes no schema for this body, only this example - transcribe its shape rather than parsing it: {"topics":["Valid Topic Name1","Valid Topic Name2"]}

[AlertOps] Delete a group. This DELETES data in AlertOps and cannot be undone from StackJack. Any escalation policy still routing to this group stops reaching anyone, and that failure is silent: the alerts keep arriving and no human is paged.

[AlertOps] Delete members from a group. This DELETES data in AlertOps and cannot be undone from StackJack. AlertOps publishes no schema for this request body. Send the object shape documented in the AlertOps API reference for this endpoint. This empties the WHOLE membership in one call, not one member. The group survives with nobody in it, so every policy still routing to it pages no-one, silently. To remove one member use alertops_delete_group_member.

[AlertOps] Delete a group's contact method. This DELETES data in AlertOps and cannot be undone from StackJack. The group stops being notified over that channel - a lost paging path rather than an error - so list what remains with alertops_list_group_contact_methods afterwards.

[AlertOps] Delete a member from a group. This DELETES data in AlertOps and cannot be undone from StackJack. That person stops being paged by every escalation policy that routes to this group. To empty the group entirely use alertops_delete_group_all_members.

[AlertOps] Delete a topic from a group. This DELETES data in AlertOps and cannot be undone from StackJack. The group stops receiving alerts carrying that topic.

[AlertOps] List a group's contact methods - the channels AlertOps uses when it notifies the group as a unit. Each row is addressed by contact method NAME, not by id.

[AlertOps] List a group's members. A member is a user or another group, so groups nest and an alert routed here can reach people one level down.

[AlertOps] List groups - the named sets of users, and of other groups, that an escalation policy can page as a unit. Start here: every other tool in this family takes the group id this returns. Paginated by OFFSET, NOT by cursor: limit is the page size (AlertOps defaults to 10 and caps it at 100; StackJack clamps out-of-range values) and offset is the row to start at, so the page after a 50-row page is offset 50. This endpoint returns no next or previous cursor - only alertops_list_alerts uses those.

[AlertOps] Update a group. This is a WHOLESALE-REPLACE write: the body replaces the entire object, so any field you omit is lost. Read the object first and send it back complete. AlertOps publishes no schema for this body, only this example - transcribe its shape rather than parsing it: {"group_name":"Group Name Sample 1","description":["TEST","test1"],"members":[{"member_type":"User","member":"testuser1","sequence":1,"roles":["Primary","Manager"]},{"member_type":"User","member":"testuser2","sequence":2,"roles":["Primary","Manager"]},{"member_type":"Group","member":"Existing Group Name","sequence":3,"roles":null}],"contact_methods":[{"email_address":"someone@somedomain.com","contact_method_name":"Primary Email","enabled":false,"sequence":1},{"country_code":"1","phone_number":"1234567890","extension":"2345","contact_method_name":"Primary Phone","enabled":false,"sequence":2},{"email_address":"someone@somedomain.com","contact_method_name":"Pager","enabled":false,"sequence":3},{"country_code":"1","phone_number":"1234567890","contact_method_name":"Group SMS","enabled":false,"sequence":4},{"url":"https://somedoamin.com","get_alert_update":false,"contact_method_name":"SLACK GROUP","enabled":true,"sequence":6}],"topics":["Valid Topic Name1","Valid Topic Name2"],"attributes":[{"attribute_name":"Attribute Name","attribute_value":"attribute value"}]} The members and contact_methods collections are part of that whole shape, so read the group back with alertops_get_group first - omitting them removes the people this group pages.

[AlertOps] Update a group's contact method. This is a WHOLESALE-REPLACE write: the body replaces the entire object, so any field you omit is lost. Read the object first and send it back complete. AlertOps publishes no schema for this body, only this example - transcribe its shape rather than parsing it: {"url":"https://somedomain.com","get_alert_update":false,"enabled":true,"sequence":2}

[AlertOps] Update a member in a group. This is a WHOLESALE-REPLACE write: the body replaces the entire object, so any field you omit is lost. Read the object first and send it back complete. AlertOps publishes no schema for this body, only this example - transcribe its shape rather than parsing it: {"sequence":1,"roles":["Primary","Manager"]}

[AlertOps] Create an inbound integration. AlertOps publishes no schema for this body, only this example - transcribe its shape rather than parsing it: {"inbound_integration_name":"string","type":"string","sequence":0,"enabled":true,"escalation_policy":"string","recipient_groups":["string"],"recipient_users":["string"],"bridge":{"telephone_number":"string","access_code":"string"},"inbound_template_id":0,"api_settings":{"is_bidirection":true,"url_mapping":{"method":"string","content":"string","source":"string","source_name":"string","static":true,"source_value":"string","source_id":"string","source_url":"string","severity":"string","source_status":"string","assignee":"string","open_alert_when":{"field_name":"string","type":"string","values":["string"]},"close_alert_when":{"type":"string","values":["string"]},"update_alert_when":{"type":"string","values":["string"]},"long_text":"string","short_text":"string","subject":"string","recipient_user":"string","recipient_group":"string","topic":"string","sample_data":"string","sample_field_value":,"custom_alert_fields":[{"attribute_name":"string","attribute_value":"string","required":true}],"attachments":{"base_path":"string","url":"string","file_name":"string","is_link":true,"is_collection":true}},"alert_tags":{"business_service":"string","component_type":"string","component_name":"string","data_center":"string","environment":"string","problem_type":"string"},"delaying_or_grouping":{"delaying_rule":{"delay":true,"delay_notifications_for_every_x_alerts":{"every_x_alerts":0},"delay_notifications_for_every_x_minutes":{"every_x_minutes":0},"delay_notifications_for_every_x_alerts_within_x_minutes":{"every_x_alerts":0,"every_x_minutes":0},"delay_notifications_until_support_hours":{"weekly_schedules":[{"name":"string","days_of_week":{"sun":true,"mon":true,"tue":true,"wed":true,"thu":true,"fri":true,"sat":true},"start_time":{"hour":0,"minute":0},"end_time":{"hour":0,"minute":0}}]}},"grouping_rule":{"group":true,"grouping_with_in_x_minutes":{"every_x_minutes":0}}},"filters_to_match_json_or_form_fields":{"add_all_filter":{"filters":[{"filter_id":0,"condition":{"field_name":"string","type":"string"},"not":true}]},"add_any_filter":{"filters":[{"filter_id":0,"condition":{"field_name":"string","type":"string"},"not":true}]}},"escalation_policy_override":{"based_on_time_of_day":{"week":{"sun":true,"mon":true,"tue":true,"wed":true,"thu":true,"fri":true,"sat":true},"start_time":{"hour":0,"minute":0},"end_time":{"hour":0,"minute":0},"escalation_policy_id":"string","escalation_policy_name":"string"},"based_on_source_data":[{"condition":{"field_name":"string","type":"string","value":"string"},"escalation_policy_id":"string","escalation_policy_name":"string"}]},"dynamic_recipient_groups":[{"condition":{"field_name":"string","type":"string","value":"string"},"recipient_group":"string","group_name":"string"}]},"mail_box":"string","email_settings":{"email_mapping":{"every_incoming_email_will_open_an_alert":true,"source_name":{"field_name":"string","start_tag":"string","end_tag":"string"},"source_identifier":{"field_name":"string","start_tag":"string","end_tag":"string"},"open_alert_when":{"field_name":"string","type":"string","values":["string"]},"close_alert_when":{"type":"string","values":["string"]},"update_alert_when":{"type":"string","values":["string"]},"ignore_duplicates":true,"long_text":{"field_name":"string","start_tag":"string","end_tag":"string"},"short_text":{"field_name":"string","start_tag":"string","end_tag":"string"},"source_url":{"field_name":"string","start_tag":"string","end_tag":"string"},"assignee_mail_official":{"field_name":"string","start_tag":"string","end_tag":"string"},"recipient_user":{"field_name":"string","start_tag":"string","end_tag":"string"},"recipient_groups":{"field_name":"string","start_tag":"string","end_tag":"string"},"topic":{"field_name":"string","start_tag":"string","end_tag":"string"},"custom_alert_fields":[{"attribute_name":"string","attribute_value":"string","required":true,"attribute_data_type":"string","start_tag":"string","end_tag":"string"}],"long_message_text":"string","short_message_text":"string","sample_data":"string"},"alert_tags":{"business_service":{"field_name":"string","start_tag":"string","end_tag":"string"},"component_type":{"field_name":"string","start_tag":"string","end_tag":"string"},"component_name":{"field_name":"string","start_tag":"string","end_tag":"string"},"data_center":{"field_name":"string","start_tag":"string","end_tag":"string"},"environment":{"field_name":"string","start_tag":"string","end_tag":"string"},"problem_type":{"field_name":"string","start_tag":"string","end_tag":"string"}},"delaying_or_grouping":{"delaying_rule":{"delay":true,"delay_notifications_for_every_x_alerts":{"every_x_alerts":0},"delay_notifications_for_every_x_minutes":{"every_x_minutes":0},"delay_notifications_for_every_x_alerts_within_x_minutes":{"every_x_alerts":0,"every_x_minutes":0},"delay_notifications_until_support_hours":{"weekly_schedules":[{"name":"string","days_of_week":{"sun":true,"mon":true,"tue":true,"wed":true,"thu":true,"fri":true,"sat":true},"start_time":{"hour":0,"minute":0},"end_time":{"hour":0,"minute":0}}]}},"grouping_rule":{"group":true,"grouping_with_in_x_minutes":{"every_x_minutes":0}}},"filters_to_match_incoming_emails":{"subject_filters":[{"filter_id":0,"condition":{"type":"string","value":"string"},"and":true,"not":true}],"body_filters":[{"filter_id":0,"condition":{"type":"string","value":"string"},"and":true,"not":true}],"sender_or_recipient_filters":[{"filter_id":0,"recipient_name":"string","recipient_address":"string","recipient_type":"string","and":true,"not":true}],"priority_filters":[{"filter_id":0,"priority":"string","and":true,"not":true}]},"escalation_policy_override":{"based_on_time_of_day":{"week":{"sun":true,"mon":true,"tue":true,"wed":true,"thu":true,"fri":true,"sat":true},"start_time":{"hour":0,"minute":0},"end_time":{"hour":0,"minute":0},"escalation_policy_id":"string","escalation_policy_name":"string"},"based_on_source_data":[{"condition":{"field_name":"string","type":"string","value":"string"},"escalation_policy_id":"string","escalation_policy_name":"string"}]},"dynamic_recipient_groups":[{"condition":{"field_name":"string","type":"string","value":"string"},"recipient_group":"string","group_name":"string"}]},"chat_settings":{"url_mapping":{"source":"string","source_name":"string","static":true,"source_value":"string"},"escalation_policy_override":{"based_on_time_of_day":{"week":{"sun":true,"mon":true,"tue":true,"wed":true,"thu":true,"fri":true,"sat":true},"start_time":{"hour":0,"minute":0},"end_time":{"hour":0,"minute":0},"escalation_policy_id":"string","escalation_policy_name":"string"}}},"heartbeat_settings":{"heartbeat_interval_in_min":0}} Additive: the route exists but raises nothing until the external system posts to it.

[AlertOps] Delete an inbound integration. This DELETES data in AlertOps and cannot be undone from StackJack. Whatever was posting to this route stops raising alerts, and that failure is silent: the monitoring system keeps sending and nobody is paged.

[AlertOps] Delete an inbound integration's filter. This DELETES data in AlertOps and cannot be undone from StackJack. Removing a filter changes what this route alerts on: events it used to drop now page, or events it used to keep no longer match.

[AlertOps] Delete inbound integration's escalation policy overrides. This DELETES data in AlertOps and cannot be undone from StackJack. This removes EVERY override on the integration at once, so all its events fall back to the default escalation policy. To remove one time-of-day override use alertops_delete_inbound_policy_overrides_tod.

[AlertOps] Delete an inbound integration's escalation policy override. This DELETES data in AlertOps and cannot be undone from StackJack. Events in that time window fall back to the integration's default escalation policy, which may page a different rotation than intended.

[AlertOps] Get one inbound event log entry - the raw payload AlertOps received and what it did with it. This is the read to use when an external system says it sent something and no alert appeared.

[AlertOps] List inbound integrations - the routes an external monitoring system uses to raise alerts in AlertOps. Start here: every inbound tool below takes the integration id this returns. Paginated by OFFSET, NOT by cursor: limit is the page size (AlertOps defaults to 10 and caps it at 100; StackJack clamps out-of-range values) and offset is the row to start at, so the page after a 50-row page is offset 50. This endpoint returns no next or previous cursor - only alertops_list_alerts uses those.

[AlertOps] Update an inbound integration. This is a WHOLESALE-REPLACE write: the body replaces the entire object, so any field you omit is lost. Read the object first and send it back complete. AlertOps publishes no schema for this body, only this example - transcribe its shape rather than parsing it: {"inbound_integration_name":"string","type":"string","sequence":0,"enabled":true,"escalation_policy":"string","recipient_groups":["string"],"recipient_users":["string"],"bridge":{"telephone_number":"string","access_code":"string"},"api_settings":{"is_bidirection":true,"url_mapping":{"method":"string","content":"string","source":"string","source_name":"string","static":true,"source_value":"string","source_id":"string","source_url":"string","severity":"string","source_status":"string","assignee":"string","open_alert_when":{"field_name":"string","type":"string","values":["string"]},"close_alert_when":{"type":"string","values":["string"]},"update_alert_when":{"type":"string","values":["string"]},"long_text":"string","short_text":"string","subject":"string","recipient_user":"string","recipient_group":"string","topic":"string","sample_data":"string","sample_field_value":,"custom_alert_fields":[{"attribute_name":"string","attribute_value":"string","required":true}],"attachments":{"base_path":"string","url":"string","file_name":"string","is_link":true,"is_collection":true}},"alert_tags":{"business_service":"string","component_type":"string","component_name":"string","data_center":"string","environment":"string","problem_type":"string"},"delaying_or_grouping":{"delaying_rule":{"delay":true,"delay_notifications_for_every_x_alerts":{"every_x_alerts":0},"delay_notifications_for_every_x_minutes":{"every_x_minutes":0},"delay_notifications_for_every_x_alerts_within_x_minutes":{"every_x_alerts":0,"every_x_minutes":0},"delay_notifications_until_support_hours":{"weekly_schedules":[{"name":"string","days_of_week":{"sun":true,"mon":true,"tue":true,"wed":true,"thu":true,"fri":true,"sat":true},"start_time":{"hour":0,"minute":0},"end_time":{"hour":0,"minute":0}}]}},"grouping_rule":{"group":true,"grouping_with_in_x_minutes":{"every_x_minutes":0}}},"filters_to_match_json_or_form_fields":{"add_all_filter":{"filters":[{"filter_id":0,"condition":{"field_name":"string","type":"string"},"not":true}]},"add_any_filter":{"filters":[{"filter_id":0,"condition":{"field_name":"string","type":"string"},"not":true}]}},"escalation_policy_override":{"based_on_time_of_day":{"week":{"sun":true,"mon":true,"tue":true,"wed":true,"thu":true,"fri":true,"sat":true},"start_time":{"hour":0,"minute":0},"end_time":{"hour":0,"minute":0},"escalation_policy_id":"string","escalation_policy_name":"string"},"based_on_source_data":[{"condition":{"field_name":"string","type":"string","value":"string"},"escalation_policy_id":"string","escalation_policy_name":"string"}]},"dynamic_recipient_groups":[{"condition":{"field_name":"string","type":"string","value":"string"},"recipient_group":"string","group_name":"string"}]},"mail_box":"string","email_settings":{"email_mapping":{"every_incoming_email_will_open_an_alert":true,"source_name":{"field_name":"string","start_tag":"string","end_tag":"string"},"source_identifier":{"field_name":"string","start_tag":"string","end_tag":"string"},"open_alert_when":{"field_name":"string","type":"string","values":["string"]},"close_alert_when":{"type":"string","values":["string"]},"update_alert_when":{"type":"string","values":["string"]},"ignore_duplicates":true,"long_text":{"field_name":"string","start_tag":"string","end_tag":"string"},"short_text":{"field_name":"string","start_tag":"string","end_tag":"string"},"source_url":{"field_name":"string","start_tag":"string","end_tag":"string"},"assignee_mail_official":{"field_name":"string","start_tag":"string","end_tag":"string"},"recipient_user":{"field_name":"string","start_tag":"string","end_tag":"string"},"recipient_groups":{"field_name":"string","start_tag":"string","end_tag":"string"},"topic":{"field_name":"string","start_tag":"string","end_tag":"string"},"custom_alert_fields":[{"attribute_name":"string","attribute_value":"string","required":true,"attribute_data_type":"string","start_tag":"string","end_tag":"string"}],"long_message_text":"string","short_message_text":"string","sample_data":"string"},"alert_tags":{"business_service":{"field_name":"string","start_tag":"string","end_tag":"string"},"component_type":{"field_name":"string","start_tag":"string","end_tag":"string"},"component_name":{"field_name":"string","start_tag":"string","end_tag":"string"},"data_center":{"field_name":"string","start_tag":"string","end_tag":"string"},"environment":{"field_name":"string","start_tag":"string","end_tag":"string"},"problem_type":{"field_name":"string","start_tag":"string","end_tag":"string"}},"delaying_or_grouping":{"delaying_rule":{"delay":true,"delay_notifications_for_every_x_alerts":{"every_x_alerts":0},"delay_notifications_for_every_x_minutes":{"every_x_minutes":0},"delay_notifications_for_every_x_alerts_within_x_minutes":{"every_x_alerts":0,"every_x_minutes":0},"delay_notifications_until_support_hours":{"weekly_schedules":[{"name":"string","days_of_week":{"sun":true,"mon":true,"tue":true,"wed":true,"thu":true,"fri":true,"sat":true},"start_time":{"hour":0,"minute":0},"end_time":{"hour":0,"minute":0}}]}},"grouping_rule":{"group":true,"grouping_with_in_x_minutes":{"every_x_minutes":0}}},"filters_to_match_incoming_emails":{"subject_filters":[{"filter_id":0,"condition":{"type":"string","value":"string"},"and":true,"not":true}],"body_filters":[{"filter_id":0,"condition":{"type":"string","value":"string"},"and":true,"not":true}],"sender_or_recipient_filters":[{"filter_id":0,"recipient_name":"string","recipient_address":"string","recipient_type":"string","and":true,"not":true}],"priority_filters":[{"filter_id":0,"priority":"string","and":true,"not":true}]},"escalation_policy_override":{"based_on_time_of_day":{"week":{"sun":true,"mon":true,"tue":true,"wed":true,"thu":true,"fri":true,"sat":true},"start_time":{"hour":0,"minute":0},"end_time":{"hour":0,"minute":0},"escalation_policy_id":"string","escalation_policy_name":"string"},"based_on_source_data":[{"condition":{"field_name":"string","type":"string","value":"string"},"escalation_policy_id":"string","escalation_policy_name":"string"}]},"dynamic_recipient_groups":[{"condition":{"field_name":"string","type":"string","value":"string"},"recipient_group":"string","group_name":"string"}]},"chat_settings":{"url_mapping":{"source":"string","source_name":"string","static":true,"source_value":"string"},"escalation_policy_override":{"based_on_time_of_day":{"week":{"sun":true,"mon":true,"tue":true,"wed":true,"thu":true,"fri":true,"sat":true},"start_time":{"hour":0,"minute":0},"end_time":{"hour":0,"minute":0},"escalation_policy_id":"string","escalation_policy_name":"string"}}},"heartbeat_settings":{"heartbeat_interval_in_min":0}} recipient_groups, recipient_users and the per-type settings blocks are part of that whole shape, so read it back with alertops_get_inbound first - omitting them silently drops the recipients this route pages.

[AlertOps] Update an inbound integration's delaying/grouping. Request body fields (AlertDelayingOrGroupingRule): delaying_rule (AlertDelayingRule); grouping_rule (AlertGroupingRule). Raising the delay or widening the grouping window makes real events page later, or fold into an alert somebody has already acknowledged.

[AlertOps] Update an inbound integration's dynamic recipient groups. This is a WHOLESALE-REPLACE write: the body replaces the entire dynamic recipient mapping, so a group left out of it stops being selectable for events from this route. Read the current mapping with alertops_list_inbound_dynamic_recipients first and send it back complete. AlertOps publishes no schema for this request body. Send the object shape documented in the AlertOps API reference for this endpoint.

[AlertOps] Change an inbound integration's status. This SUPPRESSES alerting. The failure mode is a monitoring blind spot: a real incident stops paging anyone. Request body fields (ChangeInboundIntegrationStatusRequest): enabled (boolean, required). Disabling an inbound integration is a monitoring blind spot: the external system keeps posting and no alert is raised. This is the reversible way to take a route out of service; alertops_delete_inbound is not.

[AlertOps] Create an outbound integration. AlertOps publishes no schema for this body, only this example - transcribe its shape rather than parsing it: {"outbound_integration_name":"Test Outbound Integration Name","security_type":"Basic","security":{"public_key":"","user_name":"1000031Alert@alertops.com","password":"PgY4cWdtg0RyOdrFa1ZNCFA6"},"methods":[{"method_name":"POST Issue","method_type":{"request_type":"JSON","web_method":"POST","response_data_type":"JSON","type":"REST","uri":"https://api.product.com/api/issue","request_data":"{ \\"fields\\": { \\"project\\": { \\"key\\": \\"DEMO\\" }, \\"summary\\": \\"<<MessageThread.Topic>>\\", \\"description\\": \\"<<Message.MessageText>>\\" } }","response_data":"{ \\"id\\": \\"<<Attribute.JiraIssueID>>\\", \\"key\\": \\"<<Attribute.JiraIssueKey>>\\" }","headers":"{ \\"id\\": \\"<<Attribute.JiraIssueID>>\\", \\"key\\": \\"<<Attribute.JiraIssueKey>>\\" }"},"alert_type":"10","update_alert_fields":true}]} Additive: it fires nothing at call time, but it arms a dispatch path that later alerts will use.

[AlertOps] Create an outbound integration method. AlertOps publishes no schema for this body, only this example - transcribe its shape rather than parsing it: {"method_name":"Query","method_type":{"type":"REST","uri":"https://example.com","request_type":"JSON","web_method":"GET","response_data_type":"JSON","request_data":,"response_data":,"headers":"{\\"HeaderKey1\\": \\"HeaderValue1\\", \\"HeaderKey2\\": \\"HeaderValue2\\"}"},"alert_type":"Standard Alert","update_alert_fields":false} Additive: it fires nothing at call time, but it arms a request that later alerts will send to the external system.

[AlertOps] Delete an outbound integration. This DELETES data in AlertOps and cannot be undone from StackJack. Alerts stop being pushed to that external system. Anything downstream that was creating tickets or chat messages from it goes quiet, with no error raised here.

[AlertOps] Delete an outbound integration method. This DELETES data in AlertOps and cannot be undone from StackJack. That request stops firing, so the external system stops being told about alerts this method used to push.

[AlertOps] List outbound integrations - where AlertOps pushes alerts to, such as a ticketing or chat system. Start here: every outbound tool below takes the integration id this returns.

[AlertOps] Update an outbound integration. This is a WHOLESALE-REPLACE write: the body replaces the entire object, so any field you omit is lost. Read the object first and send it back complete. AlertOps publishes no schema for this body, only this example - transcribe its shape rather than parsing it: {"outbound_integration_name":"Test Outbound Integration Name","security_type":"Basic","security":{"public_key":"","user_name":"1000031Alert@alertops.com","password":"PgY4cWdtg0RyOdrFa1ZNCFA6"},"methods":[{"method_name":"POST Issue","method_type":{"request_type":"JSON","web_method":"POST","response_data_type":"JSON","type":"REST","uri":"https://api.product.com/api/issue","request_data":"{ \\"fields\\": { \\"project\\": { \\"key\\": \\"DEMO\\" }, \\"summary\\": \\"<<MessageThread.Topic>>\\", \\"description\\": \\"<<Message.MessageText>>\\" } }","response_data":"{ \\"id\\": \\"<<Attribute.JiraIssueID>>\\", \\"key\\": \\"<<Attribute.JiraIssueKey>>\\" }","headers":"{ \\"id\\": \\"<<Attribute.JiraIssueID>>\\", \\"key\\": \\"<<Attribute.JiraIssueKey>>\\" }"},"alert_type":"10","update_alert_fields":true}]} The methods collection is part of that whole shape, so read it back with alertops_get_outbound first - omitting it silently removes the dispatch paths this integration fires.

[AlertOps] Update an outbound integration method. This is a WHOLESALE-REPLACE write: the body replaces the entire object, so any field you omit is lost. Read the object first and send it back complete. AlertOps publishes no schema for this body, only this example - transcribe its shape rather than parsing it: {"method_name":"Query","method_type":{"type":"REST","uri":"https://example.com","request_type":"JSON","web_method":"GET","response_data_type":"JSON","request_data":,"response_data":,"headers":"{\\"HeaderKey1\\": \\"HeaderValue1\\", \\"HeaderKey2\\": \\"HeaderValue2\\"}"},"alert_type":"Standard Alert","update_alert_fields":false} Changing the URI, verb or payload template changes what every future alert sends to the external system.

[AlertOps] Create a service. Additive: nobody is notified at call time. components and templates can be supplied inline here, or added afterwards with alertops_create_service_component and alertops_create_service_template. Request body fields (ServiceCreateRequest): service_name (string); show_uptime (boolean, required); components (array<ServiceComponentBaseRequest>); templates (array<ServiceTemplateBaseRequest>).

[AlertOps] Add a component to a service. Additive: nobody is notified at call time. external_id is how you tie the component to an id in your own monitoring so an inbound alert can name it. Request body fields (ServiceComponentBaseRequest): component_name (string); external_id (string).

[AlertOps] Add a message template to a service. Additive: nothing is sent at call time. The template supplies the subject and message text of future subscriber notifications. Request body fields (ServiceTemplateBaseRequest): template_name (string); message (string); subject (string).

[AlertOps] Delete a service. This DELETES data in AlertOps and cannot be undone from StackJack. Its components, templates and every subscriber relationship go with it, so the people subscribed stop being told about it. List them with alertops_list_service_users first.

[AlertOps] Delete a component from a service. This DELETES data in AlertOps and cannot be undone from StackJack, and every subscription to that component goes with it. List who is subscribed with alertops_list_service_component_users first.

[AlertOps] Delete a message template from a service. This DELETES data in AlertOps and cannot be undone from StackJack, and any notification that referenced this template loses its wording.

[AlertOps] Unsubscribe a user from a service. This DELETES data in AlertOps and cannot be undone from StackJack, and that person stops being told about this service entirely. To keep the subscription but narrow it to fewer components, use alertops_update_service_user instead.

[AlertOps] Get one service with its components and templates. The id parameter accepts the service id OR the service name; get either from alertops_list_services.

[AlertOps] Get one component of a service. Get componentId from alertops_list_service_components.

[AlertOps] Get one message template of a service. Get templateId from alertops_list_service_templates.

[AlertOps] List the subscribers to one component of a service, with the email, SMS and Slack DM flags each one is subscribed on. Read this before alertops_update_service_component_user, which replaces all three flags at once.

[AlertOps] List a service's components - the individually-tracked parts of a service that a subscriber can be subscribed to separately. Each carries a component_name and the external_id that ties it to an id in your own monitoring.

[AlertOps] List a service's subscribers, with the components each one is subscribed to. Read this before alertops_update_service_user, which replaces the whole component list.

[AlertOps] List services - the named objects that carry components, message templates and subscribers, each subscriber holding its own email, SMS and Slack DM flags. Start here: every other service tool takes the service id or name this returns. NOT PAGINATED - AlertOps returns the whole collection. Pass include with the value components or templates to get that nested collection in the same call instead of following up per service.

[AlertOps] DESTRUCTIVE (wholesale replace): an omitted component or template is removed, and a removed component takes its subscriber relationships with it. Update a service. CAUTION: components and templates are collections on this body, so read the service back with alertops_get_service and send them complete - an omitted component takes its subscriber relationships with it. Request body fields (ServiceUpdateRequest): service_name (string); show_uptime (boolean, required); components (array<ServiceComponentRequest>); templates (array<ServiceTemplateRequest>).

[AlertOps] Update a component of a service. component_id in the body must match the componentId in the path. Changing external_id breaks the link to your monitoring until you update that side too. Nothing is sent to subscribers at call time. Request body fields (ServiceComponentRequest): component_name (string); external_id (string); component_id (integer, required).

[AlertOps] Set one user's subscription to one service component. This is a WHOLESALE-REPLACE write: the body replaces the entire subscription, so a channel you omit is turned OFF rather than left alone. Send email, sms and slack_dm together every time, and read the current values with alertops_list_service_component_users first - clearing all three silently stops that person hearing about this component. Request body fields (ServiceComponentUserRequest): email (boolean, required); sms (boolean, required); slack_dm (boolean, required).

[AlertOps] Update a service's message template. template_id in the body must match the templateId in the path. This changes the wording of FUTURE subscriber notifications; nothing is sent at call time. Request body fields (ServiceTemplateRequest): template_name (string); message (string); subject (string); template_id (integer, required).