> ## Documentation Index
> Fetch the complete documentation index at: https://docs.interchange.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Bring data in

> Connect business events, finished creative, seller inventory, and source materials to the right Apostra workflow.

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.

| You have                                                      | Start here                                              | Current surface                                          |
| ------------------------------------------------------------- | ------------------------------------------------------- | -------------------------------------------------------- |
| Individual conversion or business events                      | Register an advertiser event source, then send events   | v2 REST event-source and `log-event` endpoints           |
| Aggregated CRM, MMP, or warehouse outcomes                    | Submit measurement records for a time window and entity | v2 REST measurement-data sync                            |
| An approved image, video, audio, HTML, VAST, or text creative | Import the finished asset and save a creative           | v3 `save_creative`; supported upload flows where offered |
| Seller inventory or an ad-server connection                   | Configure an inventory source and inspect its readiness | v3 source tools plus interactive credential setup        |
| A media kit, deck, rate card, site, or seller instructions    | Register material and review the extracted candidates   | v3 `save_material` and typed owner tools                 |

## 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](/v2/guides/log-events) and
[Measurement and incrementality](/v2/guides/measurement-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](/v2/setup/v3/buyer-workflows) and
[Bring your own creative](/v2/buyer/creatives/bring-your-own-creative).
Saving a creative imports content; it does not generate or revise it.
[Creative Engines](/v2/setup/v3/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](/v2/setup/v3/seller-workflows#add-and-diagnose-inventory)
for the appropriate connection test and readiness steps. Then use the
[own-supply sandbox workflow](/v2/setup/v3/seller-workflows#test-your-own-supply)
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](/v2/setup/v3/seller-workflows#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](/v3/reporting-pipeline)
to read the appropriate results back into your product.