Deploy and integrate

An API gateway covers applications that call it. It does not cover a person typing into a provider's website, and it does not cover a desktop tool that speaks its own protocol. This guide is about the other surfaces: how to get that traffic in front of CID222, and how to connect the verdicts to the systems your security team already watches.

What this guide contains

• Topologies — the six interception points side by side, what each one sees, what it cannot see, and the rule that a given hostname is inspected at exactly one of them.
• Inline proxy — CID222's own forward proxy: the opt-in compose profile, TLS interception with the appliance's proxy CA, the proxy auto-configuration file, and what the proxy actually inspects.
• ICAP and third-party gateways — the inspection contract a secure web gateway speaks to, how the listener decides who may call it, and one page per vendor.
• User-ID attribution — resolving an address to a directory user so a detection names a person rather than an address.
• Endpoint agent — Windows and Linux rollout, trust provisioning and bulk deployment.
• Browser extension — enterprise policy, device attestation and the firewall block list.
• Claude Code plugin — bringing coding-assistant traffic under the same policy.
• SIEM — outbound syslog/CEF and webhook export of detections and events.
• ITSM — handing a compliance finding to a ticketing system and reading its state back.

Every path runs the same detection pipeline against the same policy, and every verdict lands in the same All Detections feed. What differs is which traffic reaches the pipeline at all.

Before you choose

Four limits shape every topology decision. They are properties of the product and of TLS, not of a particular deployment, and none of them is removed by choosing a different topology.

• Interception needs a certificate authority the client already trusts. Where CID222 or a gateway decrypts the session, the client must trust that authority. A device you do not manage cannot be intercepted, and an application that pins its certificate cannot be intercepted even on a device you do manage.
• Chunked and resumable uploads are refused, not inspected. No path reassembles a body across requests, so a fragmented upload is blocked rather than redacted. The user sees a refusal.
• The ICAP listener cannot authenticate its peer. No secure web gateway CID222 integrates with offers a credential field on its inspection profile, so admission is by source address alone, and an admitted gateway is believed down to the username it claims.
• A hostname must be inspected at exactly one point. Text survives being inspected twice; image and file uploads do not, because the first pass re-encodes the bytes and the second refuses them.

Read Topologies with those four in mind.