This is the security summary to hand to whoever reviews the integration: what the credential is, who holds it, what data moves in each direction, and what you can switch off.
The credential
FirstIgnite connects with an API client that your Minuet administrator creates and assigns to a specific Minuet user and a specific Endpoint Access Group. There is no password, no shared login, and no per-user Minuet credential.
FirstIgnite stores both the client ID and the client secret encrypted, and the secret is never returned by any FirstIgnite API or shown in the interface, not to your users and not to your administrators after the one-time display during setup. FirstIgnite keeps bearer tokens out of application logs.
Your people sign in to FirstIgnite with their own FirstIgnite accounts. They never see or use the Minuet credential.
What happens on a request
FirstIgnite exchanges the client ID and secret for a short-lived access token from your Minuet instance, using the OAuth 2.0 client-credentials grant.
FirstIgnite calls an endpoint with that token.
Minuet checks the endpoint against the Endpoint Access Group.
Minuet applies the record permissions of the Inteum User the client runs as.
Only what passes both checks comes back.
Your Minuet instance decides how long the token lives; FirstIgnite caches it for slightly less than that and fetches a new one when it expires. FirstIgnite discards a rejected token and replaces it automatically.
The Endpoint Access Group decides which calls are allowed. The Inteum User decides which records those calls can return. Both are yours to set, and the second is the one that catches people out.
Which way the traffic goes
Almost everything is FirstIgnite's servers calling your Minuet instance over HTTPS on port 443. No FirstIgnite browser code calls the Minuet API, and Minuet doesn't need to reach anything of yours that it couldn't already. The exception is an ordinary one: an "Open in Minuet" link is a normal browser navigation that opens the record in Minuet, in the user's own Minuet session, carrying nothing from FirstIgnite.
One call goes in the other direction. Minuet's servers call FirstIgnite when your connection is first created, and for a small number of other actions Minuet initiates. Those calls are signed with HMAC-SHA256, so a captured request can't be replayed or forged. They run server to server between Minuet and FirstIgnite and don't cross your network.
For a firewalled Minuet, you allow FirstIgnite's egress addresses inbound on 443 and route that traffic to the Minuet host. Ask your FirstIgnite contact for the current address list.
FirstIgnite runs separate US and European instances, so data can stay in the region your institution is set up on.
What FirstIgnite reads
With the endpoints granted, FirstIgnite can read technologies, patents, documents, contacts, companies, Marketing Projects, Marketing Targets, remarks and agreements. It reads on demand, a page or a record at a time, and does not replicate your Minuet database. For exactly which fields it asks for and which it keeps, see What FirstIgnite reads from a Minuet technology.
Some things never cross:
Fields your Minuet hides and records the Inteum User can't see. FirstIgnite gets exactly what that user would get.
Endpoints you didn't grant. No fallback, no alternative route.
Private remarks. Remarks flagged to be excluded from reports aren't returned by the Minuet API at all, so their content never reaches FirstIgnite. The corollary matters just as much: every remark that is not flagged that way is read, whatever it contains, including correspondence with counsel. If a category of remark must never leave Minuet, flag those remarks or restrict the records with Record Access Control.
Agreement financials. FirstIgnite doesn't request royalty rates, revenue figures, estimated values, payables, billing comments or the free-text deal summary, and doesn't display them. It reads the title, status, type, direction, parties and dates.
Legacy rich-text comments. FirstIgnite doesn't read Minuet's legacy rich-text comment field and never writes to it.
Documents nobody picks. A file only moves when someone selects it.
What FirstIgnite writes
Only the operations you've turned on, and only to the fields listed here:
If you enable | FirstIgnite can write |
Sync AI Summaries to Minuet | A generated summary into the technology field you map, the Non-Confidential Summary by default. This one replaces the field's contents, with no prompt. It's off by default; the manual sync in the sidebar asks first |
CRM activity logging | An outbound email as a remark, with its recipients |
Push marketing targets | A new Marketing Target, and the company or contact it needs |
Send organizations & contacts | New companies and contacts |
Contact enrichment sync | Enrichment into the Comments field of a company or contact already linked |
Its own block. In a Comments field, FirstIgnite marks the section it owns and only ever rewrites that section. Your team's own notes are left alone. The same applies when appending a summary to a technology field.
One side effect. Logging an email can add a secondary email address to the sender's or the main recipient's Minuet contact record, so the activity attributes correctly. It never creates a contact that way and never touches other recipients' records.
Minuet's API also has no delete. FirstIgnite can create and update, but nothing it writes can be removed through the integration. That is why every write path except automatic summary sync asks you to confirm first, and why a bulk send checks for existing records before creating anything. You have to clean up a mistaken write in Minuet.
Your controls
Control | Who holds it | Effect |
Revoke the API client, or remove its Endpoint Access Group | Your Minuet administrator | FirstIgnite loses access when its current token expires |
Narrow the Endpoint Access Group | Your Minuet administrator | Removes specific capabilities |
Change the Inteum User's permissions | Your Minuet administrator | Narrows which records are visible |
Turn individual operations off | A FirstIgnite team owner or admin | Disables a feature for the whole team |
Delete the integration | A FirstIgnite team owner or admin | Removes the connection and its settings |
Revoking on the Minuet side is the hard stop, and it needs nothing from FirstIgnite. For how to scope the integration rather than switch it off, see Controlling what FirstIgnite can see.
Public project links
FirstIgnite projects can be shared through a public link. FirstIgnite fetches and shows no Minuet data on a public view. The check runs before any request to Minuet, not after. Someone with a shared link sees nothing from your CRM.
What this page doesn't cover
Where FirstIgnite stores what it reads, how long it keeps it, how customer data is separated, whether it trains AI models, and who the subprocessors are. Those belong to a formal data-flow document rather than a help article. Ask your FirstIgnite contact for it.
Related
What FirstIgnite reads from a Minuet technology lists the exact field set
Controlling what FirstIgnite can see covers Record Access Control, field permissions, and declining endpoints
What to review before you turn it on
The Minuet user the API client runs as, and what that user can see
The Endpoint Access Group's contents
Which operations you want enabled in FirstIgnite, and which stay off
Which FirstIgnite region your institution should be on
Firewall allowlisting, if you host Minuet yourselves