> ## Documentation Index > Fetch the complete documentation index at: https://docs.neoagent.io/llms.txt > Use this file to discover all available pages before exploring further. # INKY API > Triage INKY user-report tickets with INKY's own analysis of the message, close the report in INKY, and manage each client's allow list, block list, VIPs and console admins The common use is a ticket INKY opened for a message a user reported: the agent finds INKY's analysis of that message (verdict, detection reasons, where INKY delivered it, links and attachments), adds it to the ticket, and, when the review is done, confirms or rejects the user's report and resolves it in INKY. Automatically enabled when you configure INKY permissions in your agent workflow. ## What It Does * Search the analysis record INKY keeps for each inbound message, by recipient, sender, Message-ID, verdict, delivery target or detection reason * Read the mail users reported, with each report's label and comment, and the PSA ticket INKY linked * Confirm or reject a user's report, apply a safe, spam or phish verdict, or dismiss a report without a verdict * Apply an allow or block option INKY offers on a reported message * Add, change and remove allow-list and block-list rules for a client team * Add, change and remove a team's VIPs, the names INKY protects from display-name spoofing * Grant, change and revoke console roles on a team * Read your organization nodes and teams, billable mailbox usage, and each team's daily counts by verdict ## Permission Groups | Group | Covers | | - | - | | Teams and Usage | Organization nodes and client teams with their protected domains, the API key's details, mailbox usage, verdict codes (read only) | | Messages and Statistics | INKY's analysis record of each inbound message, and each team's daily counts (read only) | | Reported Mail | Reported messages and their user reports; confirming, rejecting, remediating and dismissing them | | Allow List | Allow-list rules, and applying an allow or block option INKY offers on a reported message (with Block List) | | Block List | Block-list rules | | VIPs | Each team's VIP list | | Console Admins | Who holds an INKY console role on each team, and granting, changing or revoking one | | Organization-Wide Changes | Any write addressed to an organization node. INKY applies an allow rule, a block rule or an admin grant written there to every team beneath it. The write's own group must allow it too (write only) | ## Access Profiles | Profile | What runs on its own | What asks a technician | | - | - | - | | **Read Only** | Every read | No write is allowed | | **Helpdesk** | Every read, and reported-mail reviews and verdicts | Allow-list and block-list changes. VIP, admin and organization-wide changes are off | | **IT Admin** | Every read, reported mail, block list and VIPs | Allow-list changes, console admin changes and organization-wide changes | | **Full Automation** | Every read and write | Nothing | ## Safety Controls | Control | Behavior | | - | - | | **Writes** | Neo sends only the writes INKY's API documents, each with its own method. Every other write is refused | | **Reported-message options** | Applying an option INKY offers on a reported message needs the Allow List and Block List groups, because the option can be either rule | | **Ticket scope** | On a ticket, the agent reaches only the INKY teams mapped to the ticket's company, by a name match or one you confirmed. Organization nodes and estate-wide lists are for runs with no ticket company, such as a chat | | **Organization nodes** | A write to an organization node needs Organization-Wide Changes as well as its own group, and asks for approval when either asks. A write to any other team is sent only after INKY confirms the target is a team | This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.