API integration

Use an API integration to send gateway GET requests from your backend. These screening operations are separate from the Admin API, which manages settings and reports.

Before you start, have access to your integration’s code generator and a backend that can keep secure codes private, forward visitor data, and handle service-specific response formats.

Creating the integration

1. Open Integrations and click Create.
2. Enter an Integration Name (for example, Demo API).
3. Under Select Integration Type, choose API / JSON.
4. Click Save & Proceed To Setup.

Code generator

The Code Generator tab builds the API URL used to send clicks, conversions, and impressions to 24metrics for fraud screening. Switch between CLICKS, CONVERSIONS, IMPRESSIONS, and REJECT CONVERSIONS, add the parameters you need, then copy the URL or CURL output.

Choose a service

Service	Gateway operation	Purpose
Click API	GET /api/click	Screen clicks; optional enrichment and click signing.
Conversion API	GET /api/event	Create a conversion, not look up a click or update a rejection.
Impression API	GET /api/impression	Screen impressions with impression-specific inputs and response fields.

Use the generated integration-scoped gateway host. The reference examples use integration-id.gateway.go2link.co; replace the placeholder with your integration ID or use your generated URL. Do not send Admin API keys or Bearer tokens to these endpoints.

Forward the visitor’s IP as click_ip, conversion_ip, or impression_ip, and their User-Agent as user_agent. Otherwise, backend requests can record your server’s identity instead. URL-encode each query parameter value individually. Use the backend request examples in each reference rather than sharing a parameter list across services: click and conversion mappings differ, and API impression traffic identifiers are literal.

For conversions, provide conversion_time or use_current_time=true. Conversion creation does not consume click_transaction_id for click lookup. Use the separately generated lookup or rejection workflow when that is your task; neither operation is documented by these three gateway snapshots.

How it works

• Clicks: omitted, empty, or true no_redirect normally returns compact JSON. Explicit no_redirect=false permits configured redirects or HTML, but does not guarantee a redirect. Plain blocked or ok responses are also possible. Rejected business outcomes normally use HTTP 200.
• Conversions: the normal compact response includes status and transaction ID, with reason and score for rejections. Ignored conversions return an empty HTTP 202, not an immediate screening decision.
• Impressions: use the impression response schema. Do not assume click enrichment or click signing is available.

All three services document plain-text internal errors and gateway errors that may lack a JSON Content-Type header. Handle status codes, empty bodies, and non-JSON responses before parsing a body as JSON.

What you should do with the response

For backend decision flows, implement your own handling of approved and rejected results, such as accepting, flagging, or discarding an event. Click gateway configuration can also block traffic or redirect when the request permits it. Do not assume every request returns a JSON decision or that a blank response proves rejection.

After sending traffic from your own integration, check the matching click, conversion, or impression report for the event and its screening result. Use the service-specific reason tables when a reason is returned.

Settings

General

• Active: Deactivating this integration blocks all incoming traffic.
• Enable IP Address Privacy: When enabled, IP addresses are obfuscated in reports and exports.

API Security

• Require Secure Code on Conversions: When enabled, send the Conversion Secure Code as secure for conversion creation.
• Require Secure Code on Clicks: When enabled and a Click Secure Code is configured, send it as secure for clicks.

These are separate codes. The parameter is secure, not secure_code. Keep both codes on your backend, out of browser code, public repositories, and logs. Optional click response signing uses a separate key; follow the Click API signing instructions for verification, expiry, replay protection, and key rotation. Impression requests use neither click secure codes nor click signing secrets.

Blacklisted/Whitelisted Sources

• Blocked sources listed here are excluded from reports.
• You can scope lists by clicks, conversions, or impressions, and by countries, advertisers, publishers, offers, or IPs.

Global filters

Open Global Filters on the integration and enable the click, conversion, or impression checks you need. Global filters are the fallback when no custom group matches. Use Filter Groups for source-specific matching and preset browsing. Select Done after configuring a filter drawer, then select Save changes on the page.

If Monitoring mode is enabled, rejected clicks are not blocked or redirected to the fallback or preview URL, but remain rejected in reports. Click monitoring_mode is optional enrichment requested with fields, not a field guaranteed in every response. Impression compact responses support the nested selectors impression_data.monitoring_mode and impression_data.filter_group_id; do not reuse click selectors.

Recommendations

• Remember to set up the Filters to define the screening parameters before going live.
• For rejection updates, use the REJECT CONVERSIONS tab in Code Generator and follow its generated URL. This workflow is separate from GET /api/event conversion creation and is not included in the three gateway references.