[Avanan] Take a remediation action on one or many secured entities. This QUARANTINES or RESTORES REAL EMAIL IN REAL USERS' MAILBOXES — a quarantine pulls a message out of the recipient's mailbox. The legal action strings for a given entity are NOT a fixed list: read entityAvailableActions from avanan_get_entity for that entity and use one of those exact strings. The body uses ARRAYS for scalar-looking fields: {"requestData":{"entityIds":["ENTITY_ID"],"entityActionName":["quarantine"],"entityActionParam":[""]}} — entityActionName and entityActionParam are arrays, not strings. This call is ASYNCHRONOUS: it returns one taskId per entity and the action has NOT completed when it returns. Poll each taskId with avanan_get_task_status to learn the outcome. An HTTP 200 can still carry a FAILURE in responseEnvelope.responseCode — do not assume 200 means success.

[Avanan] Get full details for one secured entity (an email, file or message) by its entity id — ids come from avanan_search_entities. The response includes entityAvailableActions: the exact action strings that are legal for THAT entity, which is what avanan_action_entity expects. Do NOT guess action names; read them from here first. Note that an HTTP 200 can still carry a FAILURE in responseEnvelope.responseCode — check the envelope, do not assume 200 means success.

[Avanan] Poll the outcome of an asynchronous action. This is the poller for BOTH avanan_action_entity AND avanan_action_event — each of those returns one taskId per targeted id, and this is the only way to learn whether the quarantine/restore/dismiss actually completed. The vendor guide documents this endpoint twice (once under Secured Entities, once under Security Events) but it is ONE operation. An HTTP 200 can still carry a FAILURE in responseEnvelope.responseCode — do not assume 200 means success.

[Avanan] Search secured entities (emails, files, messages). This is a POST that READS — the body carries filter criteria, not a mutation. A TIME WINDOW IS MANDATORY: requestData.entityFilter requires saas, startDate and endDate, and there is NO all-time query. The saas vocabulary is: office365_emails, google_mail, office365_onedrive, office365_sharepoint, ms_teams, slack, box, dropbox, sharefile. PAGINATION is an opaque scroll cursor and there is NO page-size parameter (the server chooses the batch size): the FIRST page must send "scrollId": "" (an EMPTY STRING — not null, not omitted), and every subsequent page must echo back the scrollId returned in the previous response envelope. Track progress with responseEnvelope.recordsNumber and .totalRecordsNumber. An HTTP 200 can still carry a FAILURE in responseEnvelope.responseCode — do not assume 200 means success.

[Avanan] Take an action on one or many security events — the documented action includes dismiss, which permanently closes out a real detection in the customer's Check Point console and removes it from the analyst queue. Like avanan_action_entity, the body uses ARRAYS for scalar-looking fields (event ids and the action name are arrays, not strings). This call is ASYNCHRONOUS: it returns one taskId per event and the action has NOT completed when it returns — poll each taskId with avanan_get_task_status to learn the outcome. An HTTP 200 can still carry a FAILURE in responseEnvelope.responseCode — do not assume 200 means success.

[Avanan] Get full details for one security event by its event id — ids come from avanan_search_events. An event describes a detection (phishing, malware, DLP, anomaly, ...) and links back to the secured entity it fired on, which you can then read with avanan_get_entity. Note that an HTTP 200 can still carry a FAILURE in responseEnvelope.responseCode — check the envelope, do not assume 200 means success.

[Avanan] Search security events (detections). This is a POST that READS — the body carries filter criteria, not a mutation. A TIME WINDOW IS MANDATORY: requestData.entityFilter requires saas, startDate and endDate, and there is NO all-time query. The saas vocabulary is: office365_emails, google_mail, office365_onedrive, office365_sharepoint, ms_teams, slack, box, dropbox, sharefile. PAGINATION is an opaque scroll cursor and there is NO page-size parameter (the server chooses the batch size): the FIRST page must send "scrollId": "" (an EMPTY STRING — not null, not omitted), and every subsequent page must echo back the scrollId returned in the previous response envelope. Track progress with responseEnvelope.recordsNumber and .totalRecordsNumber. An HTTP 200 can still carry a FAILURE in responseEnvelope.responseCode — do not assume 200 means success.

[Avanan] Add one entry to an Anti-Phishing list. excType is REQUIRED: whitelist or blacklist. Adding to the WHITELIST weakens a security control — it tells Anti-Phishing to stop blocking that sender/domain/IP, so a phishing campaign from it will reach mailboxes. It is reversible (remove it with avanan_delete_antiphishing_exception), which is why it is not flagged destructive, but do not treat it as a trivial edit: confirm the intended entry before adding it. Provide the JSON object body the vendor expects for the chosen list.

[Avanan] Add one entry to the Anti-Phishing BLOCK list, which makes matching mail always be treated as malicious. The vendor marks no field required here, so an over-broad entry (a bare senderDomain, say) can quarantine legitimate mail for everyone: narrow it before adding. Exactly reversible with avanan_delete_ap_exception, which is why it is not flagged destructive.

[Avanan] Add one entry to the Anti-Phishing ALLOW list. senderEmail, senderName, recipient, senderDomain and subject are all REQUIRED by the vendor. This WEAKENS a live security control: it tells Anti-Phishing to stop blocking that sender, domain or subject, so a phishing campaign matching it will reach mailboxes. It is exactly reversible with avanan_delete_ap_exception, which is why it is not flagged destructive, but confirm the entry before adding it. Reversible.

[Avanan] Add one entry to the Spam allow list. This weakens a security control — it tells the Spam engine to stop filtering that sender/domain, so unwanted or malicious bulk mail from it will land in mailboxes. It is reversible (remove it with avanan_delete_spam_exception), which is why it is not flagged destructive, but do not treat it as a trivial edit: confirm the exact sender before adding it. The list slug (spam_whitelist) is bound internally.

[Avanan] Permanently remove one entry from an Anti-Phishing list. excType is REQUIRED: whitelist or blacklist. The vendor route is a POST to a /delete/ path — it IS a delete, not a benign POST. Removing a whitelist entry re-arms blocking for that sender (mail may start being quarantined again); removing a blacklist entry stops always-blocking it. The entry cannot be recovered — re-add it with avanan_create_antiphishing_exception if this was a mistake.

[Avanan] Permanently remove one Anti-Phishing exception entry. excType must be whitelist or blacklist. The entry is gone and its settings are not recoverable from here, so read it with avanan_get_ap_exception first if you may need to recreate it. Removing an allow-list entry RESTORES blocking for that sender; removing a block-list entry STOPS forced quarantine for it. The vendor serves this as a POST to a /delete/ path, which is genuinely a delete.

[Avanan] Permanently remove one entry from the Spam allow list. The vendor route is a POST to a /delete/ path — it IS a delete, not a benign POST. Removing an entry re-arms Spam filtering for that sender, so mail the customer deliberately allowed may start being filtered again. The entry cannot be recovered — re-add it with avanan_create_spam_exception if this was a mistake. The list slug (spam_whitelist) is bound internally.

[Avanan] Get one Anti-Phishing exception entry. excType is REQUIRED and must be either whitelist (allow list) or blacklist (block list); entry ids come from avanan_list_antiphishing_exceptions for the same list. An HTTP 200 can still carry a FAILURE in responseEnvelope.responseCode.

[Avanan] Get one Anti-Phishing exception entry by list and entry id, optionally narrowed to a Check Point scope. excType must be whitelist (the allow list) or blacklist (the block list). Prefer avanan_get_antiphishing_exception unless you need the scope or scopes parameter. An HTTP 200 can still carry a FAILURE in responseEnvelope.responseCode.

[Avanan] Get one exception entry by list slug and entry id. The slug vocabulary is: whitelist (Anti-Phishing allow list), blacklist (Anti-Phishing block list), spam_whitelist (Spam allow list). Entry ids come from avanan_list_exceptions for the same slug. An HTTP 200 can still carry a FAILURE in responseEnvelope.responseCode.

[Avanan] Get one Spam allow-list entry by its id (from avanan_list_spam_exceptions). The list slug (spam_whitelist) is bound internally. An HTTP 200 can still carry a FAILURE in responseEnvelope.responseCode.

[Avanan] List the Anti-Phishing exception entries. excType is REQUIRED and must be either whitelist (the allow list — senders/domains/IPs Anti-Phishing will stop blocking) or blacklist (the block list — always treated as malicious). Anti-Phishing genuinely has BOTH lists, which is why the family cannot be bound to one slug. An HTTP 200 can still carry a FAILURE in responseEnvelope.responseCode.

[Avanan] List one Anti-Phishing exception list, optionally narrowed to a single entry id or a Check Point scope. excType must be whitelist (the allow list) or blacklist (the block list). Prefer avanan_list_antiphishing_exceptions unless you need the excId, scope or scopes parameter. An HTTP 200 can still carry a FAILURE in responseEnvelope.responseCode.

[Avanan] List every entry in one exception list, chosen by excType. The slug vocabulary is: whitelist (Anti-Phishing allow list), blacklist (Anti-Phishing block list), spam_whitelist (Spam allow list). These slugs are NOT derivable from the product names shown in the Check Point UI. If you already know the family, prefer the narrower tools: avanan_list_antiphishing_exceptions or avanan_list_spam_exceptions. An HTTP 200 can still carry a FAILURE in responseEnvelope.responseCode.

[Avanan] List every entry in the Spam allow list. The list slug (spam_whitelist) is bound internally, so there is nothing to guess — Spam has only an allow list, unlike Anti-Phishing which has both. Entries here are senders/domains the Spam engine will stop filtering. An HTTP 200 can still carry a FAILURE in responseEnvelope.responseCode.

[Avanan] Edit one existing Anti-Phishing exception entry in place. excType is REQUIRED: whitelist or blacklist. Widening a whitelist entry weakens a security control in exactly the same way as creating one — it stops Anti-Phishing blocking more traffic — and it is reversible, which is why it is not flagged destructive. The entry id comes from avanan_list_antiphishing_exceptions for the same list.

[Avanan] Edit one Anti-Phishing BLOCK-list entry in place. Read the entry with avanan_get_ap_exception first and send it back with only the intended change: widening a block-list entry can start quarantining legitimate mail for everyone it now matches. Exactly reversible, which is why it is not flagged destructive.

[Avanan] Edit one Anti-Phishing ALLOW-list entry in place. The body is the same shape the create takes, with senderEmail, senderName, recipient, senderDomain and subject required, so read the entry with avanan_get_ap_exception first and send it back with only the intended change. Widening an allow-list entry weakens a live security control in exactly the way creating one does. Exactly reversible, which is why it is not flagged destructive.

[Avanan] Edit one existing Spam allow-list entry in place. Widening an entry weakens a security control in the same way as creating one — it stops the Spam engine filtering more senders — and it is reversible, which is why it is not flagged destructive. The entry id comes from avanan_list_spam_exceptions; the list slug (spam_whitelist) is bound internally.

[Avanan] Add one URL/pattern to the Click-Time Protection exception list. This weakens a security control: an excluded URL is no longer rewritten or re-scanned when a user clicks it, so a link that later turns malicious will be followed without inspection. Beware over-broad patterns — a wildcarded domain can exempt far more than intended. It is reversible (remove it with avanan_delete_click_time_exception_item), which is why it is not flagged destructive, but do not treat it as a trivial edit.

[Avanan] Removes ALL Click-Time Protection exceptions — this wipes the entire list in one call, not a single entry. Every URL the customer had deliberately exempted from click-time rewriting returns to being rewritten and re-scanned, which can break trusted internal links and tracking URLs. There is no undo: capture the current list with avanan_list_click_time_exception_items first if it may need rebuilding. To remove one entry, use avanan_delete_click_time_exception_item instead.

[Avanan] Permanently remove ONE Click-Time Protection exception item, by its item id (from avanan_list_click_time_exception_items). The vendor route is a POST — it IS a delete. That URL/pattern returns to being rewritten and re-scanned on click, which can break a trusted internal or tracking link. The entry cannot be recovered; re-add it with avanan_add_click_time_exception_item if this was a mistake.

[Avanan] Get one Click-Time Protection exception ITEM by its id (from avanan_list_click_time_exception_items) — a single URL/pattern excluded from click-time rewriting. An HTTP 200 can still carry a FAILURE in responseEnvelope.responseCode.

[Avanan] Get one Click-Time Protection exception LIST by its id (from avanan_list_click_time_exception_lists). This returns the container's own definition — for the URL entries inside it, use avanan_list_click_time_exception_items. An HTTP 200 can still carry a FAILURE in responseEnvelope.responseCode.

[Avanan] List the individual Click-Time Protection exception ITEMS — the actual URLs/patterns that are excluded from click-time rewriting and re-scanning. Use a returned item id with avanan_get_click_time_exception_item, avanan_update_click_time_exception_item or avanan_delete_click_time_exception_item. An HTTP 200 can still carry a FAILURE in responseEnvelope.responseCode.

[Avanan] List the Click-Time Protection exception LISTS (the containers, not their entries). Use a returned list id with avanan_get_click_time_exception_list, and avanan_list_click_time_exception_items for the individual URL entries. An HTTP 200 can still carry a FAILURE in responseEnvelope.responseCode.

[Avanan] Replace/update ALL Click-Time Protection exception items in ONE call — a MASS MUTATION across the whole list, not a single-record edit. Whatever the body specifies becomes the state of every item, so entries omitted from the body can be lost. Read the current state with avanan_list_click_time_exception_items first, and prefer avanan_update_click_time_exception_item when you only mean to change one entry.

[Avanan] Edit ONE Click-Time Protection exception item in place, by its item id (from avanan_list_click_time_exception_items). Broadening an item's URL/pattern weakens a security control the same way adding one does — more links go un-rewritten and un-scanned — and it is reversible, which is why it is not flagged destructive. This affects only the named item; use avanan_update_all_click_time_exception_items only when a whole-list change is genuinely intended.

[Avanan] Create an Anti-Malware exception. This weakens a security control — it tells the Anti-Malware engine to stop blocking the named file/hash, so that file will be delivered even if it is detected as malware. Only ever exempt a hash the customer has explicitly confirmed as a false positive. It is reversible (remove it with avanan_delete_malware_exception), which is why it is not flagged destructive, but do not treat it as a trivial edit. The Anti-Malware sectool slug is bound internally.

[Avanan] Create an Anti-Malware exception with a specific exception TYPE. The vendor documents this as a distinct operation from avanan_create_malware_exception, which is why both are exposed. Like any allow-list add, this weakens a security control — the Anti-Malware engine stops blocking whatever the entry matches — and it is reversible, which is why it is not flagged destructive. The Anti-Malware sectool slug is bound internally.

[Avanan] Removes ALL Anti-Malware exceptions — this wipes the entire list in one call, not a single entry. Every file/hash the customer had confirmed as a false positive will be blocked again, so legitimate mail attachments can start being quarantined immediately. There is no undo: capture the current list with avanan_list_malware_exceptions first if it may need rebuilding. IMPORTANT: the vendor reuses the SAME POST path for creating one exception and for deleting them all — the operation is selected by the BODY, not by the path or method, so a create-shaped body sent here performs a create. To remove one entry, use avanan_delete_malware_exception.

[Avanan] Permanently remove ONE Anti-Malware exception, identified in the body (for this family by its MD5 exception string). That file/hash will be blocked again, so mail carrying it can start being quarantined. The entry cannot be recovered; re-add it with avanan_create_malware_exception if this was a mistake. IMPORTANT: the vendor reuses the SAME POST path for create-by-type and for delete — the operation is selected by the BODY, not by the path or method.

[Avanan] Get one Anti-Malware exception by its exception string. For this family the identifier IS the exception string — an MD5 hash of the exempted file — not a numeric or GUID id. Get it from avanan_list_malware_exceptions. An HTTP 200 can still carry a FAILURE in responseEnvelope.responseCode.

[Avanan] List every Anti-Malware exception — the files/hashes the Anti-Malware engine has been told not to block. Each entry is identified by its exception string, which for this family is an MD5 hash; pass that to avanan_get_malware_exception. An HTTP 200 can still carry a FAILURE in responseEnvelope.responseCode.

[Avanan] Update an existing Anti-Malware exception. The target is identified inside the body, not in the URL. Broadening an entry weakens a security control the same way creating one does — more files stop being blocked — and it is reversible, which is why it is not flagged destructive. The Anti-Malware sectool slug is bound internally.

[Avanan] Create a URL-Reputation exception. This weakens a security control — it tells the URL-Reputation engine to stop flagging that URL/domain, so mail carrying it will be delivered even if the URL is later reported as malicious. Beware over-broad domain patterns, which exempt far more than intended. It is reversible (remove it with avanan_delete_url_exception), which is why it is not flagged destructive, but do not treat it as a trivial edit. The URL-Reputation sectool slug is bound internally.

[Avanan] Create a URL-Reputation exception with a specific exception TYPE. The vendor documents this as a distinct operation from avanan_create_url_exception, which is why both are exposed. Like any allow-list add, this weakens a security control — the URL-Reputation engine stops flagging whatever the entry matches — and it is reversible, which is why it is not flagged destructive. The URL-Reputation sectool slug is bound internally.

[Avanan] Removes ALL URL-Reputation exceptions — this wipes the entire list in one call, not a single entry. Every URL/domain the customer had exempted will be scored again, so legitimate mail containing those links can start being blocked immediately. There is no undo: capture the current list with avanan_list_url_exceptions first if it may need rebuilding. IMPORTANT: the vendor reuses the SAME POST path for creating one exception and for deleting them all — the operation is selected by the BODY, not by the path or method, so a create-shaped body sent here performs a create. To remove one entry, use avanan_delete_url_exception.

[Avanan] Permanently remove ONE URL-Reputation exception, identified in the body by its exception string. That URL/domain will be scored again, so mail containing it can start being blocked. The entry cannot be recovered; re-add it with avanan_create_url_exception if this was a mistake. IMPORTANT: the vendor reuses the SAME POST path for create-by-type and for delete — the operation is selected by the BODY, not by the path or method.

[Avanan] Get one URL-Reputation exception by its exception string. For the sectool families the identifier IS the exception string itself (an MD5 hash in the Anti-Malware and DLP families; for URL Reputation it is the URL/domain entry as stored) — not a numeric or GUID id. Get the exact value from avanan_list_url_exceptions. An HTTP 200 can still carry a FAILURE in responseEnvelope.responseCode.

[Avanan] List every URL-Reputation exception — the URLs/domains the URL-Reputation engine has been told not to flag. Each entry is identified by its exception string; pass that to avanan_get_url_exception. An HTTP 200 can still carry a FAILURE in responseEnvelope.responseCode.

[Avanan] Update an existing URL-Reputation exception. The target is identified inside the body, not in the URL. Broadening an entry weakens a security control the same way creating one does — more URLs stop being flagged — and it is reversible, which is why it is not flagged destructive. The URL-Reputation sectool slug is bound internally.

[Avanan] Create a DLP exception. This weakens a security control — it tells the Data Loss Prevention engine to stop flagging the named content, so data that would otherwise have been held or alerted on can leave the organization. Only ever exempt content the customer has explicitly confirmed as a false positive. It is reversible (remove it with avanan_delete_dlp_exception), which is why it is not flagged destructive, but do not treat it as a trivial edit. The DLP sectool slug is bound internally.

[Avanan] Create a DLP exception with a specific exception TYPE. The vendor documents this as a distinct operation from avanan_create_dlp_exception, which is why both are exposed. Like any allow-list add, this weakens a security control — the DLP engine stops flagging whatever the entry matches — and it is reversible, which is why it is not flagged destructive. The DLP sectool slug is bound internally.

[Avanan] Removes ALL DLP exceptions — this wipes the entire list in one call, not a single entry. Every piece of content the customer had confirmed as a false positive will be flagged again, so legitimate outbound mail can start being held or alerted on immediately. There is no undo: capture the current list with avanan_list_dlp_exceptions first if it may need rebuilding. IMPORTANT: the vendor reuses the SAME POST path for creating one exception and for deleting them all — the operation is selected by the BODY, not by the path or method, so a create-shaped body sent here performs a create. To remove one entry, use avanan_delete_dlp_exception.

[Avanan] Permanently remove ONE DLP exception, identified in the body by its MD5 exception string. That content will be flagged again, so outbound mail carrying it can start being held or alerted on. The entry cannot be recovered; re-add it with avanan_create_dlp_exception if this was a mistake. IMPORTANT: the vendor reuses the SAME POST path for create-by-type and for delete — the operation is selected by the BODY, not by the path or method.

[Avanan] Get one DLP exception by its exception string. For this family the identifier IS the exception string — an MD5 hash — not a numeric or GUID id. Get it from avanan_list_dlp_exceptions. An HTTP 200 can still carry a FAILURE in responseEnvelope.responseCode.

[Avanan] List every DLP exception — the content the Data Loss Prevention engine has been told not to flag on its way out of the organization. Each entry is identified by its exception string, which for this family is an MD5 hash; pass that to avanan_get_dlp_exception. An HTTP 200 can still carry a FAILURE in responseEnvelope.responseCode.

[Avanan] Update an existing DLP exception. The target is identified inside the body, not in the URL. Broadening an entry weakens a security control the same way creating one does — more content stops being flagged on its way out — and it is reversible, which is why it is not flagged destructive. The DLP sectool slug is bound internally.

[Avanan] Create an anomaly exception. This weakens a security control — it tells the anomaly engine to stop raising events for the named user/behaviour, so genuinely suspicious activity of that shape (an impossible-travel login, an abnormal send burst) will no longer surface to analysts. It is reversible (remove it with avanan_delete_anomaly_exception), which is why it is not flagged destructive, but do not treat it as a trivial edit. NOTE: create and delete share the SAME POST path — the operation is selected by the BODY, not by the path or method.

[Avanan] Permanently remove one anomaly exception, identified in the body — read the exact entry from avanan_list_anomaly_exceptions first, since there is no get-by-id route in this family. The anomaly engine will start raising events for that user/behaviour again, which can flood the analyst queue if the exception was suppressing a noisy but expected pattern. The entry cannot be recovered; re-add it with avanan_create_anomaly_exception if this was a mistake. IMPORTANT: create and delete share the SAME POST path — the operation is selected by the BODY, not by the path or method, so a create-shaped body sent here performs a create.

[Avanan] List every anomaly exception — the users, behaviours or patterns the anomaly engine has been told not to raise events for. This is the only read in this family (there is no get-by-id route), so it is also how you discover the exact entry shape to pass to avanan_delete_anomaly_exception. An HTTP 200 can still carry a FAILURE in responseEnvelope.responseCode.

[Avanan] Create a sub-partner under this MSP account. name is the only field the vendor documents. Additive and removable with avanan_msp_delete_partner, which is why it is not flagged destructive. Requires the SmartAPI credentials on the connector.

[Avanan] Provision a new managed tenant under this MSP account. adminEmail, tenantName, adminName, phone, companyName and tenantRegion are all REQUIRED; MSPId assigns the tenant to a sub-partner. The tenant REGION cannot be changed afterwards, because Check Point runs each region as a completely separate service, so confirm it before creating. Additive and removable with avanan_msp_delete_tenant, which is why it is not flagged destructive. Requires the SmartAPI credentials on the connector.

[Avanan] Create a Check Point portal user under this MSP account. firstName, lastName, email, role, directLogin, samlLogin, viewPrivateData, receiveWeeklyReports and sendAlerts are all REQUIRED; MSPId assigns the user to a sub-partner. This grants a human access to the Check Point console: viewPrivateData in particular exposes message content, so set it deliberately. Additive and removable with avanan_msp_delete_user, which is why it is not flagged destructive. Requires the SmartAPI credentials on the connector.

[Avanan] Permanently remove a sub-partner from this MSP account. The vendor does not document what happens to the tenants and users assigned to it, so list them first with avanan_msp_list_tenants and avanan_msp_list_users filtered by this MSPId. Cannot be undone from here. Requires the SmartAPI credentials on the connector.

[Avanan] Permanently remove a managed tenant from this MSP account. This takes a whole customer off Check Point email protection and cannot be undone from here: recreating the tenant does not restore its configuration, licence or history. Confirm the tenant id with avanan_msp_get_tenant first. Requires the SmartAPI credentials on the connector.

[Avanan] Permanently remove an MSP portal user. The person loses Check Point console access immediately and the record cannot be restored from here. Confirm the user id with avanan_msp_get_user first. Requires the SmartAPI credentials on the connector.

[Avanan] Describe one managed tenant by its numeric id (ids come from avanan_msp_list_tenants). Requires the SmartAPI credentials on the connector. An HTTP 200 can still carry a FAILURE in responseEnvelope.responseCode.

[Avanan] Describe one MSP portal user by numeric id (ids come from avanan_msp_list_users). Read this before avanan_msp_update_user: the update replaces every documented field, so an omitted one is a change. Requires the SmartAPI credentials on the connector. An HTTP 200 can still carry a FAILURE in responseEnvelope.responseCode.

[Avanan] List the licence add-ons this MSP account can attach to a tenant. The ids returned here are what avanan_msp_upsert_tenant_license accepts in addonIdList. Requires the SmartAPI credentials on the connector. An HTTP 200 can still carry a FAILURE in responseEnvelope.responseCode.

[Avanan] Read this MSP account's licensed-seat usage for ONE DAY. year, month and day are all REQUIRED and there is no range query: read a period one day at a time. mspIds narrows to specific sub-partners (ids from avanan_msp_list_partners) and is sent as one repeated parameter per id. Paging is an opaque scroll cursor carried in the body. Requires the SmartAPI credentials on the connector. An HTTP 200 can still carry a FAILURE in responseEnvelope.responseCode.

[Avanan] List the licence types this MSP account can assign. The licenseCodeName values returned here are what avanan_msp_upsert_tenant_license requires. Requires the SmartAPI credentials on the connector. An HTTP 200 can still carry a FAILURE in responseEnvelope.responseCode.

[Avanan] Read this MSP account's licensed-seat usage for one calendar month. year and month are REQUIRED and there is no all-time query. mspIds narrows to specific sub-partners (ids from avanan_msp_list_partners) and is sent as one repeated parameter per id. Paging is an opaque scroll cursor carried in the body, as on the tenant and user lists. Requires the SmartAPI credentials on the connector. An HTTP 200 can still carry a FAILURE in responseEnvelope.responseCode.

[Avanan] List the sub-partners under this MSP account. The ids returned here are the MSPId that avanan_msp_list_tenants, avanan_msp_create_tenant, avanan_msp_list_users and the usage reads accept. Requires the SmartAPI credentials on the connector. An HTTP 200 can still carry a FAILURE in responseEnvelope.responseCode.

[Avanan] List the tenants this Check Point MSP account manages. Paging is an opaque scroll cursor carried in the body: omit bodyJson entirely for the first page, then send the scrollId the previous response returned. Narrow to one sub-partner with MSPId (ids from avanan_msp_list_partners). There is no page-size parameter. Requires the SmartAPI credentials on the connector. An HTTP 200 can still carry a FAILURE in responseEnvelope.responseCode.

[Avanan] List the Check Point portal users of this MSP account. Paging is an opaque scroll cursor carried in the body: omit bodyJson entirely for the first page, then send the scrollId the previous response returned. Narrow to one sub-partner with MSPId (ids from avanan_msp_list_partners). There is no page-size parameter. Requires the SmartAPI credentials on the connector. An HTTP 200 can still carry a FAILURE in responseEnvelope.responseCode.

[Avanan] Edit one MSP portal user in place. The body is the SAME shape the create takes, with every documented field required, so read the current record with avanan_msp_get_user first and send it back with only the intended change: an omitted field is a change, not a no-op. Raising role or viewPrivateData widens a human's access to the Check Point console, including message content. Reversible by setting the fields back, which is why it is not flagged destructive. Requires the SmartAPI credentials on the connector.

[Avanan] Set a managed tenant's licence, creating it if the tenant has none. licenseCodeName is REQUIRED (codes come from avanan_msp_list_licenses); maxLicensedUsers caps seats and addonIdList attaches add-ons (ids from avanan_msp_list_addons). Lowering maxLicensedUsers or dropping an add-on reduces what the customer is protected by, so read the current licence with avanan_msp_get_tenant first. Reversible by setting it back, which is why it is not flagged destructive. Requires the SmartAPI credentials on the connector.

[Avanan] Report the mail that PASSED sender authentication and was quarantined or judged a threat anyway, across every tenant your Check Point MSP account manages. Mail that authenticates cleanly and is still caught usually means the sending mailbox itself is compromised, so this reads as a hot list of customers to look at first. It walks the managed tenant list unless you name tenantIds, queries each tenant's security events in the window, and reads the mail behind each detection. Rows come back grouped by tenant with a per-tenant count; format="csv" returns a short-lived download link to the same columns instead, in an envelope that also carries the run's Truncated flag, TotalRows, UpstreamCalls, TenantListTruncated, UnresolvableChecks and the same per-tenant coverage (Count, EventsExamined, Truncated) as the JSON report, so a capped CSV run is visible without opening the file. IMPORTANT: Check Point's API publishes only an SPF result on a mail record - it has no DKIM or DMARC field at all - so those two always come back "unavailable", and an unavailable check is NEVER counted as a pass. With the default authPasses the report is therefore empty and says so in unresolvableChecks; pass authPasses="spf" for the report that works today. Reading another tenant's mail depends on a scope selector Check Point documents but does not define a vocabulary for, so every row is attributed from the mail's OWN customer id and a run whose tenants come back sharing one customer id is refused rather than published. Needs the SmartAPI credentials on the connector: without them you get avanan_msp_credentials_required and nothing is sent. Each row carries analysisUrl, which is the event address in Check Point API rather than a portal page - the vendor publishes no portal deep-link shape and none is invented here, so use it with eventId to look the message up. A run never fails on a cap: it returns what it has with truncated set. THREE caps raise that flag, not just the expensive one - the upstream-call budget, the per-list scroll-page cap that ends most walks and can fire on a cheap run, and the managed-tenant cap past 50 tenants - so truncated means rows were left unread, NOT that the run was large. Narrow any of them with tenantIds or a smaller days.

[Avanan] Read the scopes the connection's key is granted. Use this first when an Avanan call fails with a permission error: it separates a key that lacks a scope from a key pointed at the wrong Check Point region, which are different fixes. An HTTP 200 can still carry a FAILURE in responseEnvelope.responseCode.

[Avanan] Read the Check Point Harmony Email API root to confirm the region is answering. This exercises the token exchange and one round trip, so a failure here separates an Avanan-side outage from a StackJack-side problem before you investigate a failing tool. It says nothing about which scopes the key holds, which is what avanan_get_scopes is for.