Skip to main content
Apostra accepts several kinds of data for different jobs. An event feed supplies measurement evidence; a creative supplies the content that can run; an inventory source describes and connects supply; seller materials teach the selling workflow. Choose the path that matches what your application has.

Send events from your application

The current event ingestion route is REST. Adding the MCP connection does not install a website pixel, connect your CRM, or start a data feed.
  1. Select the owning advertiser and use a credential authorized for the v2 Buyer API. An OAuth token issued for /mcp/v3 is not a REST credential.
  2. Register the source with POST /api/v2/buyer/advertisers/:advertiserId/event-sources/sync. Use a stable event_source_id and keep delete_missing: false when adding a source without removing the others.
  3. Inspect the returned setup object. The current setup is server_only: your backend sends the events; the response does not contain a browser snippet to install.
  4. Implement the sender against POST /api/v2/buyer/advertisers/:advertiserId/log-event. Reference the registered source, use a stable event_id, and include the event time and supported identity fields.
  5. Send a fixture with test_event_code. Check the response’s received and processed counts and warnings. Test traffic is validated but excluded from production reporting and measurement.
  6. Enable production sending and inspect the advertiser’s event health and summaries. Keep the upstream event ID on retries so an event is not counted twice.
Follow the exact payload and normalization requirements in Log events and Measurement and incrementality. Identifiers must use the supported hashed or resolved forms; raw personal identifiers do not belong in these payloads. If your source has already aggregated outcomes by day or campaign, use measurement-data/sync as documented in the measurement guide. Do not turn an aggregate into invented individual events. Ingestion creates evidence only for the data actually submitted; it does not make seller delivery equivalent to conversion measurement.

Import an approved creative

Your application can create content with its own provider, retain the approved version, and bring that finished asset into Apostra.
  1. Select the advertiser and campaign that will own the work.
  2. Read the selected inventory’s accepted creative formats before choosing a final rendition.
  3. Use the supported HTTPS asset URL, inline data URL, or finalized upload reference in the current save_creative schema. Upload references have ownership and format constraints; use the documented upload flow for the asset you have.
  4. Read the saved creative, associate it with the intended buying work, and inspect destination review and readiness before launch.
The exact import and association examples are in Buyer workflows and Bring your own creative. Saving a creative imports content; it does not generate or revise it. Creative Engines has separate availability limits, and its discovery and connection tools do not themselves start a generation session.

Connect seller inventory

From the intended Seller Account, read get_status and search inventory_source to inspect existing setup. Use save_inventory_source for the source’s typed, non-secret configuration. Complete credentials or OAuth in the relevant interactive Page rather than passing provider secrets to a model. Read the source with get, requesting include: ["diagnostics"] where supported. For modular sources, include: ["modularReadiness"] shows the attached modules and lifecycle coverage. A configured connection is not proof of a successful live call: get returns recorded state and does not probe the ad server. Follow Add and diagnose inventory for the appropriate connection test and readiness steps. Then use the own-supply sandbox workflow to verify the transaction path without spending. Configuring an inventory source does not automatically publish it or satisfy live campaign readiness.

Add seller materials

Use save_material to register a URL, site, upload, crawl manifest, inline text, or historical source. For an upload, follow its preparation, byte upload, and finalization lifecycle; submitting metadata alone does not upload a file. Read the Material until processing reaches a terminal state, then inspect the extracted candidates and provenance. Review each candidate through the typed tool that owns its destination. Material-owned decisions use save_material; inventory, playbook, or other business records use their returned owner tools. An uploaded rate card is source evidence, not automatic approval to change published prices. See Add and inspect seller material for exact upload requests, processing states, and candidate decisions. Some library actions require the sales-library rollout; use the tools and capabilities your account advertises. Once your data is arriving, use Build a reporting pipeline to read the appropriate results back into your product.