> ## Documentation Index
> Fetch the complete documentation index at: https://docs.encorekit.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Overview
> Integrate premium brand offers over plain REST, with no SDK to install: you own the moment and the UI, Encore handles selection, attribution, and verification.
The Encore API is the **REST integration tier**: you own the moment and the UI, Encore returns premium brand offers (real perks brands fund to acquire customers) as plain JSON, and every economic fact (the impression, the claim, the completion) is recorded server-side. Choose it when your own code already detects the moment and you render the offer yourself; choose the [iOS](/publishers/ios/quickstart/install), [Android](/publishers/android/quickstart/install), or [Web](/publishers/web/quickstart/install) SDK when you want Encore's managed rendering and purchase plumbing.
## The flow
Every integration is the same five-stage flow; only the selection mode varies.
One `POST` in your chosen [selection mode](#choosing-a-selection-mode): ranked feed, full catalog, single message pick, or a permanent creator link.
Render the offer in your UI, message, or page. On the feed, confirm each offer's impression with [`POST /offers/impressions/{impressionUid}/delivered`](/publishers/offers-api/reference/delivered) when it is actually shown.
Route the tap to the offer's tokenized `clickUrl`. Encore records an **attributed transaction** (bound to your app, the offer, the creative, and your `userId`) and 302-redirects to the advertiser. See [The claim model](#the-claim-model).
The completion is verified server-side on the advertiser's side. Only a verified completion counts, and pays.
Encore POSTs a signed `offer_completed` event to your server: see [Receive Completion Events](/publishers/offers-api/guides/receive-completion-events).
The complete worked example of this flow is the [Rewarded Actions guide](/publishers/offers-api/guides/rewarded-actions); the guides cover only what differs per selection mode.
## Choosing a selection mode
| Mode | What you get | Use it when | Guide / Reference |
| ----------------- | -------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------- |
| **Feed** | The bandit-ranked selection for one user (up to `limit`, default 10), each offer with an `impressionUid` for per-offer exposure confirmation | The offer appears at an in-app **moment** (a milestone, a streak, a completed purchase) | [Rewarded Actions guide](/publishers/offers-api/guides/rewarded-actions) · [`POST /offers/feed`](/publishers/offers-api/reference/feed) |
| **Catalog** | The **full** set of offers a user is eligible for (entitlement + geo applied), for you to curate and order | You program a **curated surface** yourself and choose what to feature | [Curated Catalog](/publishers/offers-api/guides/curated-catalog) · [`POST /offers/catalog`](/publishers/offers-api/reference/catalog) |
| **Message** | A single offer pick (link + context fields) shaped for appending to an outbound text | You send **automated messages** (WhatsApp, Messenger, Instagram, SMS) and want one offer per conversation | [Automated Messaging](/publishers/offers-api/guides/automated-messaging) · [`POST /offers/message`](/publishers/offers-api/reference/message) |
| **Creator links** | No fetch at render time: a **permanent attributed link** per creator per campaign, plus a stats endpoint | Your platform hosts **creators** who share links in their content | [Creator Links](/publishers/offers-api/guides/creator-links) · [Creators endpoints](/publishers/offers-api/reference/creator-links) |
Rule of thumb: **if the offer appears at a moment, use the feed.** Per-offer exposure measurement (the served/delivered split below) exists only on the feed, so feed-based integrations are the ones whose impressions Encore can fully account for.
## Authentication
Every endpoint authenticates with the publishable key from your [dashboard](https://dashboard.encorekit.com), passed in the `X-API-Key` header: `pk_live_*` for production, `pk_test_*` for development.
```bash theme={null}
X-API-Key: pk_live_...
```
Integrating directly over REST with no SDK? Create a single app with platform **API** in the dashboard; you get one publishable key. If your key spans multiple platform-specific apps (a multi-app project), also send an `X-Platform` header so Encore knows which app to resolve; otherwise the request is rejected with `X-Platform header required for multi-app projects`:
```bash theme={null}
X-Platform: api # one of: ios | android | web | api
```
A single-app key does not need `X-Platform`.
**Test keys don't track.** `pk_test_...` returns offers, mints links, and accepts `delivered` calls for development, but records no impressions, clicks, or conversions. Use `pk_live_...` for anything that should show up in your dashboard.
## The impression model
The API splits "we handed you an offer" from "the user actually saw it":
* **Served (the baseline).** When the feed returns offers, the server records each returned offer as served. This is bookkeeping, not an impression: **calling the feed is not the impression**, because you fetch a batch and may only ever show some of it.
* **Delivered (the impression).** When you actually render an offer, you confirm it with [`POST /offers/impressions/{impressionUid}/delivered`](/publishers/offers-api/reference/delivered) using the per-offer `impressionUid` from the feed response. An offer you fetch but never confirm stays in the served baseline, never a confirmed impression.
This split is what makes API-tier exposure honest: the served baseline measures what Encore selected, the delivered confirmation measures what your users were shown, and the gap between them is visible instead of assumed.
## The claim model
Every offer carries a tokenized `clickUrl`. When the user taps, you open that URL; Encore records an **attributed transaction** and 302-redirects the user to the advertiser.
**A claim is not a conversion.** The claim is a fact about the offer flow: the user tapped through. The completion is verified separately on the advertiser side, and only a verified completion pays out. To react to completions from your server (grant a reward, credit a balance), use the [offer\_completed webhook](/publishers/offers-api/guides/receive-completion-events).
## What's in this section
The one end-to-end walkthrough: the complete worked feed pattern, from milestone to attributed claim
Pull your addressable inventory and curate your own surface
Append an offer to outbound automated messages
Permanent per-creator tracking links and a stats endpoint
Wire the offer\_completed webhook to react to verified completions
Endpoint contracts live in the Reference group: [`/offers/feed`](/publishers/offers-api/reference/feed), [`/offers/impressions/{impressionUid}/delivered`](/publishers/offers-api/reference/delivered), [`/offers/catalog`](/publishers/offers-api/reference/catalog), [`/offers/message`](/publishers/offers-api/reference/message), [Creator Links endpoints](/publishers/offers-api/reference/creator-links), and the [offer\_completed webhook](/publishers/offers-api/reference/offer-completed-webhook).