Build your logic

Before you begin: Scope your integration with your Index Representative. Agree on your use case, which extension points you will participate at, which mutations you will return, and which regions and channels you want to run in. Everything in this section assumes those decisions are made.

This is where you write the code that runs in the auction. By the end of this section you will have two artifacts: a gRPC service that implements the RTBExtensionPoint contract, and a Docker image that packages it for Index Cloud.

The container contract and the platform constraints are the same whatever your logic does, so this section applies equally to enrichment, deal A private auction that allows media owners to offer specific inventory directly to selected buyers identified by a deal ID. Terms are negotiated and are agreed upon before the auction occurs. and pricing decisioning, and bid shading. What differs between use cases is only the outputs you return.

What you are building

Your container exposes a single RPC, GetMutations. Index calls it with a live, privacy-safe OpenRTB An open industry standard for communication between buyers and sellers of online advertising in real-time bidding auctions. It's published by the IAB. payload, and you return structured mutations that Index validates and applies to the auction. That is the entire interface. There is no callback, no polling, and no second request.

Depending on what you scoped, your handler can activate or suppress deals, adjust floors, classify users into segments, add Extended Content IDs, or shade DSP Demand-Side Platform (DSP). A software platform that automates bidding decisions in real-time and efficiently connects buyers and audiences through an ad exchange or SSP. Also known as a buy-side platform. bids. The mutations available to you depend on which extension point the request came from, so start from the Mutation reference and work backwards to the logic you need.

Design constraints to read first

Four constraints have real architectural consequences. Read them before you choose a language, a model format, or a service topology, because each one rules out designs that would otherwise be reasonable.

Note: The no-egress constraint is the one that most often forces a rewrite. If your logic depends on a feature store or an external API call in the request path, resolve that design question before you write any code. If you need to iterate on model data after deployment, the supported path is Updating models in containers without rebuilding.

Topics in this section

1. Build a gRPC RTD service. Generate the proto bindings, implement GetMutations, and handle response codes and circuit breaker behavior. Start here.

2. Building a Docker container. Package the service: base image, required endpoints, environment variables, resource profile, and logging.

3. Implementing bid shading. Only if you are shading bids on deals you own. This is the single home for the BID_SHADE response structure, the business rules, and the handler pattern.

4. Build an HTTP RTD service (legacy). For existing HTTP integrations only. All new containers should be built for gRPC.

Keep these open while you build

• Publisher request payload reference: every signal available to your logic at the Publisher Request extension point, and how privacy settings affect it.

• Mutation reference: the schema, conditions, and examples for all six mutations.

• DSP bid response payload reference: needed only if you participate at the DSP Bid Response extension point.