Introduction

MetaRouter is a first-party server-side platform that helps customers deliver event data to third-party vendors without relying on third-party JavaScript tags. Our goal is to simplify server-to-server (S2S) event delivery by routing behavioral data collected from a customer’s website directly to your endpoint in a tagless, privacy-centric manner.

MetaRouter Integration Ecosystem

A MetaRouter integration typically consists of two core components:

1. Sync Injector (Optional, Identity Sync Layer)

The Sync Injector is used when your platform requires an identifier that MetaRouter must obtain before sending events. This enables a persistent ID to be collected and appended to every server-side event payload.

Example Use Cases:
- Cookie ID Retrieval: MetaRouter can make a GET/POST request to a vendor endpoint to retrieve a user or cookie ID from the response and persist it as a first-party cookie. The request can also include identifiers such as the MetaRouter anonymous ID or hashed PII to help vendors match users within their systems.
- Click ID Capture: MetaRouter extracts click IDs (e.g., gclid, nclid) from URL parameters and stores them for use in event payloads.

Note: If your platform only requires hashed PII, IP address, or user agent, and our first-party ID (anonymous ID) within the event payload, then no Sync Injector is needed—MetaRouter collects this from the browser by default.

2. Starter Kit (Event Delivery Layer)

The Starter Kit enables server-side transmission of customer events to your platform.

Functionality:
- Transforms and sends events such as page_view, add_to_cart, purchase, etc.
- Includes key parameters like order_id, revenue, sku, currency, etc., as required by your API.
- Data is sent via HTTP POST to your event endpoint on behalf of the customer.
Note: While POST requests are preferred for sending event data, we can support GET requests if necessary—though they are not recommended for events containing large payloads, such as detailed cart data (please see the appendix for details). Batch endpoints are also supported.

MetaRouter acts purely as a delivery mechanism. We do not store data or ingest any data from your systems.

What We Need from You

To establish this integration, we require the following information from your team:

Requirement	Description
Identifiers	List of required user identifiers. If you require cookie IDs* or click IDs, please specify how we should retrieve them (e.g., via URL param, GET request ). If the method involves an endpoint to retrieve a cookie ID, please see the Identity Endpoint for Sync Injector step below. Cookie Time-to-Live (TTL) – How long should the vendor Id remain valid before it expires?
Event Ingestion Endpoint	Event Ingestion Endpoint – An endpoint where MetaRouter can send server-side event data via HTTP POST, typically using a JSON request body (`application/json`). If your API requires a different format (for example, URL query parameters or `application/x-www-form-urlencoded` bodies), please specify. API Documentation – Please provide documentation for your event ingestion API (for example: Snapchat Conversions API: https://developers.snap.com/api/marketing-api/Conversions-API/UsingTheAPI The Trade Desk Realtime Conversion API: https://partner.thetradedesk.com/v3/portal/data/doc/post-track-realtimeconversion) Required Headers – Please provide a list of any headers your endpoint expects (excluding authentication). MetaRouter sends the following headers by default: `Accept-Encoding: application/json` `Content-Type: application/json` Rate Limits – Please specify any API rate limits or request thresholds that MetaRouter should account for. Batch Support – If your API supports batching multiple events in a single request, please indicate the supported format and limits. For considerations and requirements related to GET-based event ingestion, please refer to the Appendix - Event Ingestion: GET Endpoint
Identity Endpoint for Sync Injector_(if applicable)_	Identity Sync Endpoint URL – The endpoint MetaRouter should call to generate a vendor-side user ID (separate from the event ingestion endpoint). This endpoint may receive values such as IP address, user agent, anonymous ID, or other identifiers. CORS Configuration (if applicable) – If your identity sync endpoint restricts requests using CORS allowlists, please ensure the MetaRouter test domain `https://demo.metarouter.io` is permitted for development and validation. Please see Appendix - Identity Sync for further considerations.
Consent & Privacy Classification	To ensure your integration respects end-user consent preferences within MetaRouter's Consent Module, please provide the following so we can assign the correct consent category to your integration Primary platform function - example: Advertising/Targeting, Analytics/Measurement, Personalization, Social Media, Performance. Brief description of how received event data will be used (e.g., audience building, attribution, personalization). Any existing consent classification - e.g., OneTrust category code, IAB TCF 2.0 vendor ID, or Google Consent Mode v2 parameters your platform maps to (ad_storage, analytics_storage, etc.). Primary regulatory regions your customers operate in (EU/GDPR, US/CCPA, both, other).
Validation Method	Access to a test account or test credentials so we can validate the integration during development. We’ll also need clear instructions on how to confirm data delivery—whether that’s through an event dashboard, a backend contact for validation, or other available methods.

Client-Side Functionality Not Supported via Server-to-Server Delivery

While MetaRouter supports the delivery of user and event data via server-to-server methods, we do not replicate functionality that requires a client-side tag to manipulate the browser or user interface in real time. Removing a client-side tag and relying solely on server-side delivery may result in the loss of the following capabilities:

Experiments or A/B testing
Heat maps and behavior analytics
Widgets or in-page embedded tools
Displaying personalized creatives (e.g., banners or content swaps)
Chat and customer support modules
Pop-up displays or modals
Other browser-dependent or real-time display features

If your product depends on any of these features, please raise them during integration planning to assess whether removing the client-side tag would introduce limitations.

Final Notes

MetaRouter enables your platform to receive clean, structured event data from enterprise customers without requiring your tag to be deployed. By working together, we can offer a privacy-conscious, high-performance alternative to traditional browser-based tracking.

If your platform does not yet support S2S ingestion, we're happy to collaborate on defining a simple API format that works for both sides.

Thank you for partnering with MetaRouter.

Appendix

Event Ingestion: GET endpoint

GET Endpoint Considerations - While MetaRouter strongly recommends HTTP POST for event ingestion, we can support GET-based event endpoints if required. However, GET delivery introduces technical limitations that must be reviewed carefully before implementation.

LIMITATIONS OF GET ENDPOINTS

URL Length Constraints - Most servers, browsers, and intermediary proxies enforce URL length limits in the low-kilobyte range (commonly around ~2 KB). This restricts:

Large order payloads (e.g., multiple products in a cart)
Rich metadata or extended attributes
Nested or structured data formats

If event payloads exceed the supported URL length, delivery may fail.

No Request Body Support - Requests using GET should only be used to retrieve data and generally should not contain a request body.

Native JSON is not reliably supported with GET. Any structured data must be encoded into query parameters.
Values must be URL-encoded

This limits payload flexibility and increases implementation complexity.

Authentication Constraints - While GET requests can technically include headers, many GET-based implementations rely on query-parameter authentication rather than header-based authentication (e.g., Authorization: Bearer token), which is the modern API standard. If authentication is required, it typically must be passed via:

Query parameters (e.g., ?api_key=XXXX)
Or a custom header (if your infrastructure explicitly supports it for GET)

Note: Passing credentials via query string may introduce additional security considerations.

Limited Batching Support - GET endpoints typically require one request per event, which results in:

Higher request volume
Increased operational overhead
No support for batching multiple conversions in a single request
Reduced scalability for high-traffic customers

Manual Encoding & Escaping - Complex values (e.g., product arrays) must be:

Flattened into query string format
Delimited consistently (e.g., comma-separated, pipe-delimited, indexed fields)
Properly escaped and URL-encoded

Note: Improper encoding can lead to parsing failures.

REQUIRED INFORMATION FOR GET INTEGRATIONS

If your platform requires GET-based ingestion, please provide the following:

Request Constraints

What is your server’s maximum supported URL length (in characters)?
What is the maximum allowed length for individual query parameters?
How should multiple items (e.g., cart products) be passed?
- Comma-separated
- Pipe-delimited
- Indexed fields (item1, item2, etc.)
Are special characters (e.g., &, ,, %) allowed in parameter values?
Do you require specific encoding or escaping rules?
Does your endpoint require query parameters to appear in a specific order within the URL?

Authentication & Security

Do you support authentication for GET requests?
If yes, how should credentials be passed?
- API key in query parameter?
- Header-based authentication (if supported)?
Are there rate limits we should account for?
Do you require IP allowlisting/whitelisting?

Payload & Schema

What are the required parameters for each event type (e.g., purchase, lead)?
Do you accept custom parameters, or is the schema fixed?
What user identifiers do you accept (e.g., email, phone, IP address, click ID, vendor ID)?
Should identifiers be hashed or sent raw?

Testing & Debugging

Do you have a test mode, sandbox, or debug endpoint?
What HTTP response codes should we expect?
Will error logs or rejection reasons be available for failed requests?

Deduplication

Do you support deduplication via an event_id or similar unique identifier?
If so, what is the required format and retention window?

Important Note - Due to the limitations outlined above, MetaRouter strongly recommends POST-based ingestion for event data whenever possible, particularly for purchase or cart-based events. GET ingestion should only be used when no POST alternative is available.

Identity Sync Endpoint Considerations

If your integration requires an identity sync endpoint for generating or retrieving a vendor-side user ID, the following considerations will help ensure compatibility with MetaRouter’s Sync Injector implementation.

CLIENT-SIDE EXECUTION

MetaRouter’s Sync Injector runs client-side within the browser. As a result, the identity sync request is subject to standard browser restrictions and behavior.

HEADER AND COOKIE RESTRICTIONS

Because the request is executed client-side, some headers and cookies may not be accessible or readable due to browser security restrictions.

For example:

Certain headers (such as Set-Cookie) cannot be programmatically read by browser-based requests.
Cookies set on different domains or blocked third-party cookies may not be accessible.
Some browser-controlled or forbidden headers cannot be accessed or modified.

REDIRECT-BASED SYNCING

MetaRouter generally does not support redirect-based identity syncing workflows, as these approaches are increasingly deprecated and may introduce issues such as:

Broken referral tracking
Increased bounce rates
Disruption to conversion funnels

If needed, MetaRouter can send vendor cookie values using standard request credentials (credentials: include) instead of relying on redirects.